From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adWtT-00084a-Oq for qemu-devel@nongnu.org; Wed, 09 Mar 2016 00:42:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adWtQ-0007Uy-IW for qemu-devel@nongnu.org; Wed, 09 Mar 2016 00:42:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adWtQ-0007UQ-Az for qemu-devel@nongnu.org; Wed, 09 Mar 2016 00:42:44 -0500 References: <1457194595-16189-1-git-send-email-eblake@redhat.com> <1457194595-16189-5-git-send-email-eblake@redhat.com> <87si0182tj.fsf@blackfin.pond.sub.org> <56DEF7C5.7070801@redhat.com> <878u1s3hy7.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <56DFB7D3.5090503@redhat.com> Date: Tue, 8 Mar 2016 22:42:43 -0700 MIME-Version: 1.0 In-Reply-To: <878u1s3hy7.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uxsE4kssAN8d5SUIqH3HwtF0QpwBsJpPK" Subject: Re: [Qemu-devel] [PATCH v4 04/10] qapi: Emit implicit structs in generated C 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) --uxsE4kssAN8d5SUIqH3HwtF0QpwBsJpPK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/08/2016 12:09 PM, Markus Armbruster wrote: >=20 >> I think what would sway me over the fence is looking at some of our >> constructs: for example, qapi-types.py has gen_object() which it now >> calls recursively. When called directly from visit_object_type(), we >> have all the pieces; when called from visit_alternate_type(), we have = to >> create a 1-element members array; and when called recursively, we have= >> to manually explode base into the four pieces. >=20 > What could be improved if we changed visit_object_type() to take a > QAPISchemaObjectType instead of name, info, base, members, variants? >=20 > I believe we'd leave gen_object() unchanged to keep > visit_alternate_type() simple. >=20 > Here's a different one: we could drop visit_object_type_flat(). Indeed. But I'd rather get v5 of this series out sooner rather than later, so I'll save the change for a later day. >>> >>> Uh, these are "always reserved for use as identifiers with file scope= " >>> (C99 7.1.3). I'm afraid we need to use the q_ prefix. Seems doable. We already reserved q_ for ourselves (commit 9fb081e0), so far using it mainly by c_name. There's still the risk that c_name adds q_ onto something ticklish which then clashes with our use of q_ on an implicit type for something else; except that we haven't declared 'obj' as ticklish. > I feel awful generating >100KiB of code that gets included pretty much > every time we compile anything. Perhaps the proper fix for that is to > find out *why* we include qapi-types.h so much, then figure out how to > include it much, much less. >=20 > Here's a guilty one: error.h. I believe it includes qapi-types.h just > for QapiErrorClass. I guess it's only in the QAPI schema to have > QapiErrorClass_lookup[] generated. I'd gladly maintain those nine(!) > lines of code manually if it helps me drop >100KiB of useless code from= > many (most?) compiles. Commit 13f59ae predates my work on qapi, but I think you're right that error.h including qapi-types.h is a big offender and appears to do so solely for ErrorClass. But how about as a followup series, so that v5 gets out the door sooner. >=20 > Another one are builtin QAPI types. A few headers want them. We could= > put them into a separate header instead of generating them into > qapi-types.h. Could also enable getting rid of the ugly "spew builtins= > into every header, but guard them with #ifdeffery" trick. In that same series. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --uxsE4kssAN8d5SUIqH3HwtF0QpwBsJpPK 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/ iQEcBAEBCAAGBQJW37fTAAoJEKeha0olJ0NquC4IAJMTkQQohAJ7PZAU+yNL2Qfd opMrI8RONAFv+s3PH61UGoX4lwOETr42/CsjljuuWz+P/25gKJaizkb1RsLTI5cG cw1HpAnL8VqLs6jsPjnFbnSEC4VRIXRYgF64cAQgShAGUdJ0sw45Fgu0EjeqnCEp llF8ClDkaCUh13gwm6nO05mwNVw4kkzqEw5bT/zxz7RvmpET9shX+JpgYGRdDCwa vCIpOI9gyHFNEoJRwCG13IRtR9duNRdrpMUe1oaWz4J6YT69SO0Eep7iTvNmVtyN 3/rS1cM0/c6E2k5o/WthmNHxN550pya/fpGhRp89EsQSHh36yP3Sm5WXk4H2/88= =oeWP -----END PGP SIGNATURE----- --uxsE4kssAN8d5SUIqH3HwtF0QpwBsJpPK--