From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W89Bf-0005B5-9Z for qemu-devel@nongnu.org; Tue, 28 Jan 2014 08:58:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W89Ba-0004p5-BC for qemu-devel@nongnu.org; Tue, 28 Jan 2014 08:58:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W89Ba-0004oy-2b for qemu-devel@nongnu.org; Tue, 28 Jan 2014 08:58:42 -0500 Message-ID: <52E7B78A.8000102@redhat.com> Date: Tue, 28 Jan 2014 06:58:34 -0700 From: Eric Blake MIME-Version: 1.0 References: <1390488396-16538-1-git-send-email-akong@redhat.com> <1390488396-16538-5-git-send-email-akong@redhat.com> <20140124104831.GA11239@T430.nay.redhat.com> <20140127081756.GB2572@amosk.info> <52E62910.5050303@redhat.com> <20140127104631.GA13148@T430.redhat.com> <20140128104547.GA24312@amosk.info> <52E79132.1030705@redhat.com> In-Reply-To: <52E79132.1030705@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U9KbmrndTtwk2sLgtBnBvhbvEdvFr6DCV" Subject: Re: [Qemu-devel] [PATCH v4 4/5] qmp: full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Amos Kong , Fam Zheng Cc: qemu-devel@nongnu.org, libvir-list@redhat.com, mdroth@linux.vnet.ibm.com, lcapitulino@redhat.com, qiaonuohan@cn.fujitsu.com, xiawenc@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U9KbmrndTtwk2sLgtBnBvhbvEdvFr6DCV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/28/2014 04:14 AM, Paolo Bonzini wrote: >> Let's see the feedback of Eric. >=20 > Eric's feedback is certainly useful, but I think we need to look at it > from the QEMU perspective more than the libvirt perspective. >=20 > Passing the raw schema and letting libvirt parse it is a Really Bad ide= a > from the QEMU perspective, in my opinion, even if it means a little mor= e > work now and even if libvirt is willing to add the parser. Libvirt wants to parse formal qapi, not pseudo-JSON. I still have on my to-do list to read the v4 schema and make sure that libvirt can live with it. >=20 > First and foremost, the current "pseudo-JSON" encoding of the schema is= > nothing but a QEMU implementation detail. The "pseudo-JSON" syntax > definitely shouldn't percolate to the QAPI documentation. Using normal= > QAPI structs means that the normal tool for documentation > (qapi-schema.json doc comments) applies just as well to QAPI schema > introspection Agreed - I definitely want the output of the query command to be fully described by qapi. Which means we DO have to convert from the pseudo-JSON of the qapi file into the final formal qapi format. But the conversion is known at code generation time, so you should do it as part of your python code generator, and not repeat the conversion at runtime in the C code. That is, the C code should have everything already split out into the data structures it needs to just output the qapi structure as documented for the formal qapi definition. >=20 > Second, if one day we were to change the schema representation from > "pseudo-JSON" to something else, we would have to carry a "pseudo-JSON"= > serializer for backwards compatibility. Building QAPI structs and > relying on the normal formatting machinery is very different from > putting together strings manually. >=20 > The schema must be emitted as JSON data, not as a string. I'm not > willing to compromise on this point. :) Nor am I. The output MUST be formal JSON, described by the qapi (whether we change the syntax of qapi-schema.json and tweak the .py code generators in the future should not matter, the output of the QMP command will be the same formal JSON). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --U9KbmrndTtwk2sLgtBnBvhbvEdvFr6DCV 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJS57eKAAoJEKeha0olJ0Nqrt4IAIOrJDMJks6txIXtTTE8i/Tl anppo4EOv8S2+wC/SqFcSuqGIqhzJvhhTZS9Lg/NXqIMwDvr0ew6tV5soCRO4szp d0bQy5Mnb1cHEN9ubq7Y8xvkyH6OCytuCMA70orQojLjEuc0T37lW+bb1y8VFQyT Drpi39J9H24OLR66A36IvqM3R3xnZgybbXnWit+9hfO2vSRI8eAOaGlmWuv0653V V6aq5VRTKp4Wv3kcRO006sEWAP9g2/jLdMuMQzYj5pNMdxiADtUxfwduuXEsdXjA 5RakJ/jEDNxukw3vF2snbAy26qxWzq+TaQSYiSeyTlr/Sg9ANowb6xwsOrR7JBw= =povd -----END PGP SIGNATURE----- --U9KbmrndTtwk2sLgtBnBvhbvEdvFr6DCV--