From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad4V9-0006ZE-Pz for qemu-devel@nongnu.org; Mon, 07 Mar 2016 18:23:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ad4V6-0007JR-Jb for qemu-devel@nongnu.org; Mon, 07 Mar 2016 18:23:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ad4V6-0007JM-CR for qemu-devel@nongnu.org; Mon, 07 Mar 2016 18:23:44 -0500 References: <1455665965-27638-1-git-send-email-eblake@redhat.com> <87h9h7iltx.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <56DE0D7E.6020404@redhat.com> Date: Mon, 7 Mar 2016 16:23:42 -0700 MIME-Version: 1.0 In-Reply-To: <87h9h7iltx.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iIEWsobreGTDjsi5QdQFwxS1twcMNqTDO" Subject: Re: [Qemu-devel] [PATCH] qapi-visit: Honor prefix of discriminator enum List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iIEWsobreGTDjsi5QdQFwxS1twcMNqTDO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/17/2016 05:05 AM, Markus Armbruster wrote: > Let's check for completeness. Calls of c_enum_const(): >=20 > * QAPISchemaEnumType.c_null() and (with your patch) gen_visit_union() > call it like >=20 > c_enum_const(TYPE.name, MEMBER, TYPE.prefix) >=20 > where MEMBER is a member of enumeration type TYPE. >=20 > As your patch shows, the prefix is easy to forget. A safer function > would take just TYPE and MEMBER: >=20 > TYPE.c_member(MEMBER) >=20 I took a look at this email again today, and while it still sounds like a nice action, I wasn't able to get it done quickly (certainly not 2.6 material, at any rate). > * gen_event_send() calls >=20 > c_enum_const(event_enum_name, name) >=20 > where name is member of the enum type named event_enum_name. That's > okay because the type is auto-generated without a prefix. Regardless= , > we could do something like >=20 > schema.lookup_type(event_enum_name).c_member(name) >=20 > Requires actually constructing the type, which is probably a good ide= a > anyway, because it gets us the necessary collision checks. Replacing= > global event_enum_name by event_enum_type would be nice then. Out of= > scope for this patch. >=20 > * gen_enum_lookup() and gen_enum() work on name, values, prefix instead= > of the type. I figure they do to support qapi-event.py. If we clean= > it up to create the type, these functions could use the type as well,= > and then c_enum_const() could be dropped. Well, they also do it to support qapi-types.py, where the visit_enum_type() visitor callback has already broken things out into name/values/prefix instead of providing a type, and where we don't have easy access to the schema to do schema.lookup_type(name). As I've worked more with the visitors, I'm really wondering if visit_enum_type(self, type, info) would be a saner callback interface than visit_enum_type(self, type.name, info, type.values, type.prefix) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --iIEWsobreGTDjsi5QdQFwxS1twcMNqTDO 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/ iQEcBAEBCAAGBQJW3g1+AAoJEKeha0olJ0Nq1T4H/idA/l6IbpH9x/fxryeiGBMp TpDity6HvZ8LyJmA7u7TADnVZNSzee1PwnI+3sjXbJo9ZSSYoF3+ZL85yrQ0jtUQ NQPEuDPwjqVNbWM7v8a4oPbjZOZtllI8t6ZQW9NjU86j29sw1QgvN2PIBg1s78dM rPp2gPmviQytZxx3+2MYjMtwY1tPCmcQuLC65GxYei/aw/Wi+FI1ziL8eflc0RXY m3Z2+MSePy3uquRusrsSJ5e6P9PHVPROW2nm0MMRAVfR45SCdc7rQtFQ7gQPrwv/ V3FQypjogAOmQn+Lc8ag9lMh5dYBi+ejC1mewbDUFbeijQTWAngw+qsiNeVdGRY= =Wi+Y -----END PGP SIGNATURE----- --iIEWsobreGTDjsi5QdQFwxS1twcMNqTDO--