qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v2 10/12] mc: expose tunable parameter for c


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC PATCH v2 10/12] mc: expose tunable parameter for checkpointing frequency
Date: Fri, 04 Apr 2014 08:56:58 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 04/03/2014 11:29 PM, Michael R. Hines wrote:
>> I'm trying to thing of a back-compat method, which exploits the fact
>> that we now have flat unions (something we didn't have when
>> migrate-set-capabilities was first added).  Maybe something like:
>>
>> { 'type': 'MigrationCapabilityBase',
>>    'data': { 'capability': 'MigrationCapability' } }
>> { 'type': 'MigrationCapabilityBool',
>>    'data': { 'state': 'bool' } }
>> { 'type': 'Migration CapabilityInt',
>>    'data': { 'value': 'int' } }
>> { 'union': 'MigrationCapabilityStatus',
>>    'base': 'MigrationCapabilityBase',
>>    'discriminator': 'capability',
>>    'data': {
>>      'xbzrle': 'MigrationCapabilityBool',
>>      'auto-converge': 'MigrationCapabilityBool',
>> ...
>>      'mc-delay': 'MigrationCapabilityInt'
>>    } }
>>
>> along with a tweak to query-migrate-capabilities for full back-compat:
>>
>> # @query-migrate-capabilities
>> # @extended: #optional defaults to false; set to true to see non-boolean
>> capabilities (since 2.1)
>> { 'command: 'query-migrate-capabilities',
>>    'data': { '*extended': 'bool' },
>>    'returns': ['MigrationCapabilityStatus'] }
>>

> 
> I like this a lot - it's very complicated, but it is clean, I think.

Good - that means I made sense in trying to explain it.  And the more I
re-read my mail, the more I like the idea - fewer new commands, and make
the existing commands both more powerful and more easily extensible, all
while still being discoverable by libvirt without waiting for full
schema introspection.

> 
> Maybe you should add some "reserved" fields in there as well
> to the union, in case you want to expand the number of members
> of the union in the future?

Adding members to a union is back-compat safe.  No need to reserve
slots, we just add them when we have a use for them.  Besides, how would
you reserve a slot?  QAPI requires a name (not just a type) - but unless
you know what to name your slot, you can't really reserve it.  (We are
NOT worried about C ABI compatibility, where a union type must be large
enough to occupy enough bytes for any future larger structs carved into
the union - we are only worried about QAPI API compatibility which
requires a name for each branch of the union)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]