From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqm9E-0005cg-4Y for qemu-devel@nongnu.org; Tue, 18 Nov 2014 12:01:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xqm99-00066d-5v for qemu-devel@nongnu.org; Tue, 18 Nov 2014 12:01:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34637) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqm98-00066U-NA for qemu-devel@nongnu.org; Tue, 18 Nov 2014 12:00:55 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAIH0qUZ028058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 18 Nov 2014 12:00:53 -0500 Message-ID: <546B7B43.1090507@redhat.com> Date: Tue, 18 Nov 2014 10:00:51 -0700 From: Eric Blake MIME-Version: 1.0 References: <1414639364-4499-1-git-send-email-famz@redhat.com> <1414639364-4499-3-git-send-email-famz@redhat.com> <545CC25E.5090405@redhat.com> <546B7771.2070608@redhat.com> In-Reply-To: <546B7771.2070608@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OEXrWaxTsvUT6p9UuWTQGTS14I2SBP4eH" Subject: Re: [Qemu-devel] qmp-commands.hx and inherited types (Was: Re: [PATCH v6 02/10] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: Max Reitz , Fam Zheng , qemu-devel@nongnu.org, Stefan Hajnoczi , Markus Armbruster This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OEXrWaxTsvUT6p9UuWTQGTS14I2SBP4eH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/18/2014 09:44 AM, John Snow wrote: >> Is it worth using type inheritance, as in: >> >> { 'type': 'BlockDirtyBitmapAdd', >> 'base': 'BlockDirtyBitmap', >> 'data': { '*granularity': 'int' } } >> >=20 > Strictly speaking, I would argue against inheritance here because > "BlockDirtyBitmapAdd" is not "isa" "BlockDirtyBitmap". It's more of a > "Hasa" relationship. Fair enough. >=20 > At any rate, I tried to implement this for giggles to see if I could, > and ran into the following issue with which I'd be curious to get an > answer for. >=20 > As an example, If you have some type: >=20 > { 'type': 'example', > 'data': { 'foo': 'int' } } >=20 > And an extension of it: >=20 > { 'type': 'academicExample' > 'base': 'example', > 'data': { 'bar': 'str' } } >=20 > How would you write a command that expected both "foo" and "bar"? > The following doesn't seem appropriate (the generated code SKIPS the > base fields, which leads to missing arguments in the prototype: >=20 > { 'command': 'academic-command', > 'data': 'academicExample' } Ouch. Sounds like a bug in the code generator. Obviously, someone will have to patch that (and add a testsuite entry to make sure it doesn't regress) before we can rely on it. >=20 > ... >=20 > { > .name =3D "academic-command", > .args_type =3D "foo:i,bar:s", > .mhandler.cmd_new =3D qmp_marshal_input_academic_command, > }, >=20 >=20 > The generated prototype appears to skip the "foo" argument, including > only the arguments associated with the base type, in this case, 'bar'. >=20 > Do we support this kind of use? I didn't see it in-use currently, but I= > only gave it a cursory skimming. We supposedly document it as working, but as no one is using it (including no testsuite entry), I'm not surprised that it doesn't work ye= t. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --OEXrWaxTsvUT6p9UuWTQGTS14I2SBP4eH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJUa3tDAAoJEKeha0olJ0NqbCgH/25h6cOkZ3FxBQywMOPEutaU nGufEcNIFgsTqcp5/BcEsd5nV8wvlVHaSH+8hOUtOy/MyqDhP4S5iq4p+OSxI6r5 YjNMus6sx4klfEmQx9vcswZwJn2hBA66UwAfbUTAVOqszegKgKqtI7pm/ijYruHZ 43AT6wgJSsHtYKui7Qf9OnTVFOQGs4uMj0pGy/SxQd4OC/4+eGl+SIg9FGNjFSxY OUGUQSEoKQukBXsNTpcf+d4ZXJfzD/5tBHt0kEsC7LQzVhbgB4J8IQQTgFMa94VQ vz2mFPOOo+gPZNv6rglTxHbd3BV54M+TJpWWHJc9W7O/wZvVLj4QMaj7FhKgyao= =X/Q9 -----END PGP SIGNATURE----- --OEXrWaxTsvUT6p9UuWTQGTS14I2SBP4eH--