From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45472) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgyDf-0007tX-Rq for qemu-devel@nongnu.org; Wed, 22 Oct 2014 11:53:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XgyDa-00039s-Gx for qemu-devel@nongnu.org; Wed, 22 Oct 2014 11:53:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XgyDa-00039o-8v for qemu-devel@nongnu.org; Wed, 22 Oct 2014 11:52:58 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MFqvvR014371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 22 Oct 2014 11:52:57 -0400 Message-ID: <5447D2D7.6030202@redhat.com> Date: Wed, 22 Oct 2014 09:52:55 -0600 From: Eric Blake MIME-Version: 1.0 References: <1413359710-2799-1-git-send-email-quintela@redhat.com> <1413359710-2799-3-git-send-email-quintela@redhat.com> <20141020102408.GF2517@work-vm> <87egu357yl.fsf@elfo.elfo> <544527BB.1060500@redhat.com> <20141022111851.GD2296@work-vm> <87vbnccoz1.fsf@blackfin.pond.sub.org> In-Reply-To: <87vbnccoz1.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HrhfPbWgtenJBRSvKGJlEDHUpmWaqb911" Subject: Re: [Qemu-devel] [PATCH 2/7] runstate: Add runstate store List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , "Dr. David Alan Gilbert" Cc: kwolf@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, laine@redhat.com, lcapitulino@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HrhfPbWgtenJBRSvKGJlEDHUpmWaqb911 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/22/2014 05:40 AM, Markus Armbruster wrote: >> I think the question here really comes from RunState being an enum def= ined >> in qapi-schema.json; so we could use that directly in the migration st= ream >> if we were guaranteed that the encoding of that enum wasn't going to c= hange. >> Does qapi make any guarantees about the enum encoding? >=20 > qapi-code-gen.txt in master is silent on the matter: >=20 > =3D=3D=3D Enumeration types =3D=3D=3D >=20 > An enumeration type is a dictionary containing a single key whose v= alue is a > list of strings. An example enumeration is: >=20 > { 'enum': 'MyEnum', 'data': [ 'value1', 'value2', 'value3' ] } >=20 > Eric's "drop qapi nested structs" series improves the spec a lot. And I still need to find time to supply the next revision of that series.= =2E. > The enumeration values are passed as strings over the QMP protocol,= > but are encoded as C enum integral values in generated code. While= > the C code starts numbering at 0, it is better to use explicit > comparisons to enum values than implicit comparisons to 0; the C co= de > will also include a generated enum member ending in _MAX for tracki= ng > the size of the enum, useful when using common functions for > converting between strings and enum values. Since the wire format > always passes by name, it is acceptable to reorder or add new > enumeration members in any location without breaking QMP clients; > however, removing enum values would break compatibility. For any > complex type that has a field that will only contain a finite set o= f > string values, using an enum type for that field is better than > open-coding the field to be type 'str'. >=20 > I figure relying on the QAPI code generator assigning values 0, 1, 2 in= > order is fair. If you want to guarantee that more explicitly in the > spec, patch welcome (on top of Eric's, please). Yes, the generator guarantees that the order that enums are listed in a =2Ejson file will be the 0, 1, 2, ... values assigned in the C code. I'l= l add that in my revision. You cannot rely on the C values being stable unless the .json file takes care to not reorder names for the enum members; if we have enums where the C code is going to rely on a particular ordering, we probably ought to document that in the .json file (since MOST enums are designed for the C code to use them solely by symbolic name and not by specific value). >=20 > A test or build-time assertion checking the values don't change would b= e > prudent. A comment next to the enum definition warning against > incompatible changes wouldn't hurt. Indeed, if you are going to rely on something that the generator happens to give but does not guarantee, then additional build-time checking and documentation is called for. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --HrhfPbWgtenJBRSvKGJlEDHUpmWaqb911 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 iQEcBAEBCAAGBQJUR9LXAAoJEKeha0olJ0NqWd4H/i6JgAGRYv1/9wKJHHH4O54E A+PqyF13aIv3LIuJ/BlWOwNWl1iOvdikClwdBvPLhizWpSV8oFIE5ZnuP4WKwqWj P7hMQikq408XLPAHafFoCHM1Ng46rDf2Q6EkWeNdRdwB3cFok8dt7BRFIel0xpYQ JaQsm6QRVK30pcHVeVkAO7S/KU+qdoLVbsT/oWu0Sy0AOeCWfXqOvy1tChD0li+R 5mnT4TKUf1LbuvQITbXQZOdvonYCQ/O+7Sb49TVOHsbTuaoyz/+niQjxvd6p9E7d CwzxRKDtvp2An+49vU105IMRAQcAROT2YFzBa74s3BIiiCcSMXLzrjfqE+Uu8ko= =0hoX -----END PGP SIGNATURE----- --HrhfPbWgtenJBRSvKGJlEDHUpmWaqb911--