From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr5Jf-0001Uy-39 for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:33:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zr5Jb-0007T9-CK for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:33:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zr5Jb-0007Sj-5T for qemu-devel@nongnu.org; Tue, 27 Oct 2015 10:33:31 -0400 References: <1445898903-12082-1-git-send-email-eblake@redhat.com> <1445898903-12082-23-git-send-email-eblake@redhat.com> From: Eric Blake Message-ID: <562F8B39.40704@redhat.com> Date: Tue, 27 Oct 2015 08:33:29 -0600 MIME-Version: 1.0 In-Reply-To: <1445898903-12082-23-git-send-email-eblake@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AuWXE6rwn9iogM6oCpc3w273cUk4AfiQo" Subject: Re: [Qemu-devel] [PATCH v11 22/24] qapi: Finish converting to new qapi union layout List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: armbru@redhat.com, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AuWXE6rwn9iogM6oCpc3w273cUk4AfiQo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/26/2015 04:35 PM, Eric Blake wrote: > We have two issues with our qapi union layout: > 1) Even though the QMP wire format spells the tag 'type', the > C code spells it 'kind', requiring some hacks in the generator. > 2) The C struct uses an anonymous union, which places all tag > values in the same namespace as all non-variant members. This > leads to spurious collisions if a tag value matches a QMP name. You asked for an updated commit message (but that request was made against v10: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg06216.html). There, you suggested "a non-variant member name" rather than "QMP name" - it works for me, but you'd want to make that change for all of 13-22/25 (since I copy-pasted the same intro to each). Or decide which ones you want to squash together. For your other comment in that mail (mentioning an example test), I think I already got close to what you asked for, but have one tweak below= : >=20 > This patch is the back end for a series that converts to a > saner qapi union layout. Now that all clients have been > converted to use 'type' and 'obj->u.value', we can drop the > temporary parallel support for 'kind' and 'obj->value'. >=20 > Given a simple union qapi type: >=20 > { 'union':'Foo', 'data': { 'a':'int', 'b':'bool' } } >=20 > this is the overall effect, when compared to the state before > this series of patches: >=20 > | struct Foo { > |- FooKind kind; > |- union { /* union tag is @kind */ > |+ FooKind type; > |+ union { /* union tag is @type */ > | void *data; > | int64_t a; > | bool b; > |- }; > |+ } u; > | }; >=20 > There are still some further changes that can be made to the > testsuite now that there is no longer a collision between > enum tag values and QMP names, as well as adding a reservation > of 'u' to avoid a collision between QMP and our choice of union > naming, but those will be later patches. Change this paragraph to something along these lines: The testsuite still contains some examples of artificial restrictions (see flat-union-clash-type.json, for example) that are no longer technically necessary, now that there is no longer a collision between enum tag values and non-variant member names; but fixing this will be done in later patches, in part because some further changes are required to keep QAPISchema*.check() from asserting. Also, a later patch will add a reservation for the member name 'u' to avoid a collision between a user's non-variant names and our internal choice of C union name. >=20 > Note, however, that we do not rename the generated enum, which > is still 'FooKind'. A further patch could generate implicit > enums as 'FooType', but while the generator already reserved > the '*Kind' namespace (commit 4dc2e69), there are already QMP > constructs with '*Type' naming, which means changing our > reservation namespace would have lots of churn to C code to > deal with a forced name change. >=20 > Signed-off-by: Eric Blake >=20 > --- --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --AuWXE6rwn9iogM6oCpc3w273cUk4AfiQo 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/ iQEcBAEBCAAGBQJWL4s5AAoJEKeha0olJ0Nq59IH/1PngsJw2hzJBgCpaGo/HL72 Zhc+WBd20N+tLkNB0ZA7yDmn702NKFK4b6mh87vuA/S5C41vudqdC1/+PhPJhc4W e0i6lgwONq9GAI01EklTLeHLbQ3mmSuj3lK/onXUe8eLjIxoeZvOwSjGFE/6pG8f RxeHjNv0qyusoA7xpvJR9J7PQ7Hh2b21QzhYNz3xKzjyRbWaBqotLoFV4o47mSFm zVvP7eUI6he51+Yi71azUd0kc2icpMxRtwUCfMrJn6/au4EK4VNrZCr4/unsZHAR 9J0UzKgE/KGyTbwOfSW87/n9lN7yDc+GRX6iDkzxtB+jEDs/Ff00hVDwEyYgytg= =rk/T -----END PGP SIGNATURE----- --AuWXE6rwn9iogM6oCpc3w273cUk4AfiQo--