From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abqms-0004A6-Ly for qemu-devel@nongnu.org; Fri, 04 Mar 2016 09:33:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abqmn-0001gO-Ns for qemu-devel@nongnu.org; Fri, 04 Mar 2016 09:33:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abqmn-0001gJ-Fm for qemu-devel@nongnu.org; Fri, 04 Mar 2016 09:32:57 -0500 References: <1456443528-13901-1-git-send-email-eblake@redhat.com> <1456443528-13901-17-git-send-email-eblake@redhat.com> <87egbr4sqw.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <56D99C96.3010007@redhat.com> Date: Fri, 4 Mar 2016 07:32:54 -0700 MIME-Version: 1.0 In-Reply-To: <87egbr4sqw.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="svxcnmH9s5o3SJeco7MjDpt4wOspS9fw4" Subject: Re: [Qemu-devel] [PATCH v2 16/19] qapi: Allow anonymous base for flat union 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) --svxcnmH9s5o3SJeco7MjDpt4wOspS9fw4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/03/2016 06:04 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> Rather than requiring all flat unions to explicitly create >> a separate base struct, we can allow the qapi schema to specify >> the common members via an inline dictionary. This is similar to >> how commands can specify an inline anonymous type for its 'data', >=20 > Suggest to end the sentence here, and then... >=20 >> and matches the fact that our code base already has several >> flat unions that had to create a separate base type that is used >> nowhere but in the union. >=20 > "We already have several struct types that only exist to serve as a > single flat union's base. The next commits will clean them up." >=20 > Replace "them" by "some" if you don't clean them all up. >=20 > It's a nice step towards having a variant record type in the schema > language similar to what we have in introspection. >=20 >> @@ -63,7 +62,8 @@ void visit_type_%(c_name)s_members(Visitor *v, %(c_n= ame)s *obj, Error **errp) >> c_name=3Dc_name(name)) >> >> if base: >> - ret +=3D gen_visit_members_call(base, '(%s *)obj' % base.c_na= me()) >> + ret +=3D gen_visit_members_call(base, 'qapi_%s_base(obj)' % c= _name(name), >=20 > I started at this for several minutes until I could guess what's going > on here. >=20 > The old code works fine when the type isn't implicit. >=20 > When it is, it fails the assertion in base.c_name(), even though > gen_visit_members_call() is not going to use its value. >=20 > You hack around it by passing 'qapi_NAME_base(obj)' instead. >=20 > If NAME isn't implicit, the function exists, and does the same as the > expression it replaces. >=20 > If NAME is implicit, the function doesn't exist, but > gen_visit_members_call() doesn't care, because it doesn't use the > argument then. >=20 > Ugh! More evidence that we better not munge the two cases together int= o > one function. Even with my v4 work towards exposing implicit types as a concrete struct, I'm still not creating qapi_NAME_base(obj) for objects with an implicit type. But '(_obj_FOO_base *)FOO' works well for a base with a concrete implicit base type. >> @@ -354,7 +355,7 @@ code generator can ensure that branches exist for = all values of the >> enum (although the order of the keys need not match the declaration o= f >> the enum). In the resulting generated C data types, a flat union is >> represented as a struct with the base member fields included directly= , >> -and then a union of structures for each branch of the struct. >> +and then a union of pointers to structures for each branch of the str= uct. >=20 > Uh, that became wrong in commit 544a373 already, didn't it? >=20 > Is that a bug in PATCH 3 then? Yes, and fixed up accordingly in my v3 respin. (I think it was some rebase conflicts that I resolved incorrectly at some point). >> +++ b/tests/qapi-schema/qapi-schema-test.json >> @@ -75,14 +75,10 @@ >> 'base': 'UserDefZero', >> 'data': { 'string': 'str', 'enum1': 'EnumOne' } } >> >> -{ 'struct': 'UserDefUnionBase2', >> - 'base': 'UserDefZero', >> - 'data': { 'string': 'str', 'enum1': 'QEnumTwo' } } >> - >> # this variant of UserDefFlatUnion defaults to a union that uses fiel= ds with >> # allocated types to test corner cases in the cleanup/dealloc visitor= >> { 'union': 'UserDefFlatUnion2', >> - 'base': 'UserDefUnionBase2', >> + 'base': { 'string': 'str', 'enum1': 'QEnumTwo' }, >=20 > You lost member 'integer' from the base's base. Harmless (I think), bu= t > visible when you compare generated output. Easy enough to keep. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --svxcnmH9s5o3SJeco7MjDpt4wOspS9fw4 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/ iQEcBAEBCAAGBQJW2ZyWAAoJEKeha0olJ0NqqIcH/jC/lr4dQQaqTZjkMg3w6I/I z2Qyiv3A88tOFlFScHmgY0N10sPYXIzZuNEyJ0EiqFUf9U2LJJpSnDuyvT6+uGLR FOE8VrBQNyTJeNlzK2dcjoDuoar6/gYMHK4TXuRMbHhlrdIpWK0/P7ab9eNhuQbf BtbSlWsx4KbfP3zmOtkHC96i46QMQb4bW+8WQItmuO+MIOrRTSh1ztnLH0OEzsEp SVLHG9Ko9DANiddJXCS5pY5fGN1UFSg4qjCZbBn11UvMkURr+2mrLXEqQZh6y86t X1l4wCfX0Y+bUsOeGBiPGuMz1/1ydw+tNDysJC5PatVEJvHSW/TbA+730/dC/ko= =A+na -----END PGP SIGNATURE----- --svxcnmH9s5o3SJeco7MjDpt4wOspS9fw4--