From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwYxK-0006XF-IM for qemu-devel@nongnu.org; Wed, 11 Nov 2015 12:15:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwYvE-00086d-N0 for qemu-devel@nongnu.org; Wed, 11 Nov 2015 12:13:10 -0500 References: <1447224690-9743-1-git-send-email-eblake@redhat.com> <1447224690-9743-22-git-send-email-eblake@redhat.com> <8761188p36.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <564374D8.7060700@redhat.com> Date: Wed, 11 Nov 2015 10:03:20 -0700 MIME-Version: 1.0 In-Reply-To: <8761188p36.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oWCWf1L6TvK1bNtGOc0VqL5iWa8Wnpqwr" Subject: Re: [Qemu-devel] [PATCH v11 21/28] qapi: Convert qtype_code into qapi enum type List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Michael Roth , qemu-devel@nongnu.org, "open list:Block layer core" , Luiz Capitulino This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oWCWf1L6TvK1bNtGOc0VqL5iWa8Wnpqwr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/2015 09:42 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> What's more meta than using qapi to define qapi? :) >> >> Convert qtype_code into a full-fledged[*] builtin qapi enum type, >> so that a subsequent patch can then use it as the discriminator >> type of qapi alternate types. Doing so is easiest when renaming >> it to qapi conventions, as QTypeCode. >=20 > Out of curiosity: why does the rename make the conversion easier? It guarantees I found all affected instances. (Although I guess the rename could be split to a separate patch from making it builtin). It makes sure that if we later tighten rules about naming, we won't have to whitelist 'qtype_code' as an anomaly to our conventions. >=20 > If we rename anyway, what about renaming to QType? Hmm, we burned that= > on a struct we use only internally in qobject/. Oh well. Internal structs are often easy to rename. So if we want to avoid the need for 'prefix', I could certainly try to achieve that (move internal QType out of the way, then rename qtype_code to QType, then make QType the builtin). Looks like this one patch just became three :) >=20 >> Fortunately, there are not >> many places in the tree that were actually spelling the type name >> out, and the judicious use of 'prefix' in the qapi defintion >=20 > definition I've got to quit coding late at night - my rate of typos increases :) >> +++ b/docs/qapi-code-gen.txt >> @@ -163,6 +163,7 @@ The following types are predefined, and map to C a= s follows: >> accepts size suffixes >> bool bool JSON true or false >> any QObject * any JSON value >> + QTypeCode QTypeCode JSON string of enum QTypeCode values >=20 > QTypeCode is currently used only internally, so the JSON values don't > matter. I don't expect that to change. However, we either enforce > internal use somehow, or document the JSON values. Documenting them is= > easier. >=20 > In short, your patch is fine. >=20 >> - >> -struct QObject; >> +#include "qapi-types.h" >> >> typedef struct QType { >> - qtype_code code; >> + QTypeCode code; >> void (*destroy)(struct QObject *); >> } QType; >> > typedef struct QObject { > const QType *type; > size_t refcnt; > } QObject; >=20 > Note: typedef name QObject still defined here. Oh, I see what you're saying. Since qapi-types.h now has a forward declaration of the QObject typedef, this could be changed to just struct QObject { =2E.. }; >> +++ b/scripts/qapi-types.py >> @@ -233,8 +233,14 @@ class QAPISchemaGenTypeVisitor(QAPISchemaVisitor)= : >> self.defn +=3D gen_type_cleanup(name) >> >> def visit_enum_type(self, name, info, values, prefix): >> - self._fwdecl +=3D gen_enum(name, values, prefix) >> - self._fwdefn +=3D gen_enum_lookup(name, values, prefix) >> + # Special case for our lone builtin enum type >> + if name =3D=3D 'QTypeCode': >=20 > Would "if not info" work? Same in qapi-visit.py below. Feels a bit hacky, since we just recently added is_implicit() to hide (and then change) the 'if not info' check on objects. Maybe an accessor is_builtin() makes more sense? But yes, same approach to both client fil= es. >> -#include "qapi/qmp/qobject.h" >> + >> +typedef struct QObject QObject; >=20 > Typedef name QObject now also defined here. GCC accepts this silently > without -Wpedantic, but other compilers might not. Whether we care for= > such compilers or not, defining things in exactly one place is neater. >=20 > Possible fixes: >=20 > * Drop the typedef from qobject.h >=20 > * Don't add it to qapi-types.h, and use struct QObject there >=20 I favor dropping the second typedef. >> +++ b/scripts/qapi.py >> @@ -33,7 +33,7 @@ builtin_types =3D { >> 'uint32': 'QTYPE_QINT', >> 'uint64': 'QTYPE_QINT', >> 'size': 'QTYPE_QINT', >> - 'any': None, # any qtype_code possible, actually >> + 'any': None, # any QTypeCode possible, actually >> } >> >=20 > Should we list QTypeCode here? Yeah, probably. This array is only used by the ad hoc parser, and may disappear later as we move more into check(), but we should be consistent in the meantime. >=20 >> # Whitelist of commands allowed to return a non-dictionary >> @@ -1243,6 +1243,11 @@ class QAPISchema(object): >> self.the_empty_object_type =3D QAPISchemaObjectType(':empty',= None, None, >> [], None) >> self._def_entity(self.the_empty_object_type) >> + self._def_entity(QAPISchemaEnumType('QTypeCode', None, >> + ['none', 'qnull', 'qint',= >> + 'qstring', 'qdict', 'qli= st', >> + 'qfloat', 'qbool'], >> + 'QTYPE')) >> >> def _make_implicit_enum_type(self, name, info, values): >> name =3D name + 'Kind' # Use namespace reserved by add_name= () > [Trivial changes to expected test output snipped] I debated about hacking tests/qapi-schema/test-qapi.py to omit QTypeCode (the way we already omit builtin types and things like 'intList'), for less churn in the .out files. I can go either way, if you have a preference. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --oWCWf1L6TvK1bNtGOc0VqL5iWa8Wnpqwr 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/ iQEcBAEBCAAGBQJWQ3TYAAoJEKeha0olJ0NqGXAH/REGTp7Qcx9mVRcEd4djqUpK +H/Rez5QYQeqcbWF3OZymSZOrsnDFL6tEDDdiW5CLuV/Vjhhvuhg3QF051OQtqGn alJ0AHuih+06c/CbVRal+tl/ZnwuI9jswD+J9FHZSlYpRf20zABvMgJKv6SQ7ws+ XmwVGQVjqCI0+ubvrAxijFQ/CS1OuA345RD+3RYvn5cdiSkMuxkKSkH7uGpyFPTS VsACnVRZF8+QBGH8hY2GwUeNZ3VRyk/Lw+5H/TWOLiQxDQ1p+X8pfIwoa6e5EI2t KWP9+aRGGlL6G1RXh7GqNT/dzKErL9cywAYCCiZO/WHhexXYmmVkbtTKwcoLGFo= =bmOJ -----END PGP SIGNATURE----- --oWCWf1L6TvK1bNtGOc0VqL5iWa8Wnpqwr--