From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WW5Ys-0007hT-Vq for qemu-devel@nongnu.org; Fri, 04 Apr 2014 10:57:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WW5Yo-00018o-10 for qemu-devel@nongnu.org; Fri, 04 Apr 2014 10:57:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WW5Yn-00018Q-P0 for qemu-devel@nongnu.org; Fri, 04 Apr 2014 10:57:37 -0400 Message-ID: <533EC83A.1090005@redhat.com> Date: Fri, 04 Apr 2014 08:56:58 -0600 From: Eric Blake MIME-Version: 1.0 References: <1392713429-18201-1-git-send-email-mrhines@linux.vnet.ibm.com> <1392713429-18201-11-git-send-email-mrhines@linux.vnet.ibm.com> <531F84FD.7010608@redhat.com> <87mwgwz8ja.fsf@elfo.mitica> <531F9300.50304@redhat.com> <533E4331.2020202@linux.vnet.ibm.com> In-Reply-To: <533E4331.2020202@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a6UL0dDc7utTqduemkOhetMTFOvhFam0D" Subject: Re: [Qemu-devel] [RFC PATCH v2 10/12] mc: expose tunable parameter for checkpointing frequency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael R. Hines" , quintela@redhat.com Cc: GILR@il.ibm.com, SADEKJ@il.ibm.com, pbonzini@redhat.com, abali@us.ibm.com, qemu-devel@nongnu.org, EREZH@il.ibm.com, Luiz Capitulino , owasserm@redhat.com, onom@us.ibm.com, hinesmr@cn.ibm.com, isaku.yamahata@gmail.com, gokul@us.ibm.com, dbulkow@gmail.com, junqing.wang@cs2c.com.cn, BIRAN@il.ibm.com, lig.fnst@cn.fujitsu.com, "Michael R. Hines" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a6UL0dDc7utTqduemkOhetMTFOvhFam0D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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-boole= an >> capabilities (since 2.1) >> { 'command: 'query-migrate-capabilities', >> 'data': { '*extended': 'bool' }, >> 'returns': ['MigrationCapabilityStatus'] } >> >=20 > 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. >=20 > 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) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --a6UL0dDc7utTqduemkOhetMTFOvhFam0D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTPsg7AAoJEKeha0olJ0NqF9cIAJhcWDHcGCDdnTjMIOTKUTle oMM7bByjibEDoMO2pft4wmuto2xdf0P+53wxV4jN2whXYwbUoU5FAaBMGlr4MLQx lDrpyb1RrA615WbQLTJ9XX8F7S7huZvxf3R+4GQRvRQWhu2+rkFuxZFmJfzzfReR HTcMsfEGEghETI2LNArDXPxVYj6tmlgwrzJ5FThtaw2AgcYhekE7/jkjtqMSmzEi mhtsAmuULHfK7Lt00UbPbhVFvI5RbVZgA3PMSCoI9dQVw3W19/X3VzkS9AAqPNHS Np+HcCS+jUDBSFFO6swcLrZcEoePVccv1Z8859H9oN0oXdxHEfiC/tiLDs2549c= =yoo0 -----END PGP SIGNATURE----- --a6UL0dDc7utTqduemkOhetMTFOvhFam0D--