[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
signature.asc
Description: OpenPGP digital signature