From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKqpC-0001Xu-Ny for qemu-devel@nongnu.org; Thu, 30 Jul 2015 12:36:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKqp7-0005VP-RX for qemu-devel@nongnu.org; Thu, 30 Jul 2015 12:36:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKqp7-0005V7-K7 for qemu-devel@nongnu.org; Thu, 30 Jul 2015 12:36:49 -0400 References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-27-git-send-email-armbru@redhat.com> <55B95DAA.3040302@redhat.com> <87oaiu5eox.fsf@blackfin.pond.sub.org> <55BA1CAE.8030405@redhat.com> <87si85y747.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55BA528F.5050907@redhat.com> Date: Thu, 30 Jul 2015 10:36:31 -0600 MIME-Version: 1.0 In-Reply-To: <87si85y747.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U02f48oLNwa5Ro0stjA8PdLOL1KKgKDkK" Subject: Re: [Qemu-devel] [PATCH RFC v2 26/47] qapi-types: Convert to QAPISchemaVisitor, fixing flat unions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U02f48oLNwa5Ro0stjA8PdLOL1KKgKDkK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/30/2015 09:53 AM, Markus Armbruster wrote: >> Or, we could ditch the qtypes lookup altogether, and merely create the= >> alternate enum as a non-consecutive QTYPE mapping, for one less level = of >> indirection, as in: >> >> typedef enum BlockdevRefKind { >> BLOCKDEV_REF_DEFINITION =3D QTYPE_QOBJECT, >=20 > QTYPE_QDICT, but I get what you mean. >=20 >> BLOCKDEV_REF_REFERENCE =3D QTYPE_QSTRING, >> }; >> >> then rewrite visit_get_next_type() to directly return the qtype, as we= ll >> as rewrite the generated switch statement in visit_type_BlockdevRef() = to >> directly inspect the qtypes it cares about. In fact, that's the >> approach I'm currently playing with. >=20 > Hmm. The schema currently doesn't let you control enumeration values. For public enums. But the enum for alternate is never public - you never send the name of the branch over the wire, so we don't need to stringize the name anywhere. > qapi-code-gen.txt specifies: >=20 > The enumeration values [...] 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 code will also include a generated enum > member ending in _MAX for tracking the size of the enum, useful whe= n > using common functions for converting between strings and enum > values. >=20 > Strictly speaking, this needn't apply to implicit enums like > BlockdevRefKind. But is it a good idea to make them different? I think so, but maybe under a different name (maybe BLOCKDEV_REF_REFERENCE_QTYPE) to make it more obvious that this is not the usual generated enum, but special to the alternate. >=20 > Hmm, your new BlockdevRefKind is basically a subset of qtype_code with > the members renamed. Could we simply use qtype_code directly? We could, except that clients that manipulate the generated struct then have to know the qtype mapping directly; while keeping symbolic names lets them do 'foo->type =3D BLOCKDEV_REF_REFERENCE; foo->reference =3D xy= z;' as a nice visual indicator of which union member within the struct is being assigned according to the discriminator. I guess I'll see how much code currently manipulates the generated structs (I already recall from other patches in this series that blockdev played a bit loose by validating that the QMP was okay and then using QDict for everything else rather than the generated struct) and make my decision when posting my RFC patch. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --U02f48oLNwa5Ro0stjA8PdLOL1KKgKDkK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVulKPAAoJEKeha0olJ0Nq1CQH/21diXD6CHDhoOzvgRXK5mox fp00nroEjpoDe1V15h7fpG8cxnExvUydLFgk0G1LGsb9AKxNKEzGzIcs+DWrC9h5 uqRp/VgpNhqotAyGLZE7IBncOKPvfmOE4j5cnB+PnkFOmmOisEh74aDCJGl1DhNh GSRaoVWTzPREMcq1xba9/AhePM43k09YUehpopaLc6waH61NWaG8ZUIJT+oCljaq 7X2C81q2t7RjEdAKTnsc19FRn38dt7hejMTZEvdxTJBlb/stAB7n/AQL63ykpYgW 0gur1KNC1czmN86SyUmlM0HxZjVh+iJcFc9pDQnDqdrOoSAh7Op2ijCgtl4HuSw= =8+GW -----END PGP SIGNATURE----- --U02f48oLNwa5Ro0stjA8PdLOL1KKgKDkK--