From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49565) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXbSg-0002nE-3p for qemu-devel@nongnu.org; Thu, 03 Sep 2015 16:50:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXbSc-0007K2-UN for qemu-devel@nongnu.org; Thu, 03 Sep 2015 16:50:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36777) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXbSc-0007Ju-N4 for qemu-devel@nongnu.org; Thu, 03 Sep 2015 16:50:18 -0400 References: <1441290623-13631-1-git-send-email-armbru@redhat.com> <1441290623-13631-31-git-send-email-armbru@redhat.com> From: Eric Blake Message-ID: <55E8B288.3090700@redhat.com> Date: Thu, 3 Sep 2015 14:50:16 -0600 MIME-Version: 1.0 In-Reply-To: <1441290623-13631-31-git-send-email-armbru@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S7xABM9k3ANwQgcVxdiD66FT6dnVOfoI3" Subject: Re: [Qemu-devel] [PATCH RFC v4 30/32] qapi: New QMP command query-schema for QMP schema introspection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org Cc: mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S7xABM9k3ANwQgcVxdiD66FT6dnVOfoI3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/03/2015 08:30 AM, Markus Armbruster wrote: > qapi/introspect.json defines the introspection schema. It's designed > for QMP introspection, but should do for similar uses, such as QGA. [review to follow in separate message; I'm using this message to focus on one point for easier tracking of the sub-thread] >=20 > The introspection schema does not reflect all the rules and > restrictions that apply to QAPI schemata. A valid QAPI schema has an > introspection value conforming to the introspection schema, but the > converse is not true. >=20 > Introspection lowers away a number of schema details, and makes > implicit things explicit: >=20 > * The built-in types are declared with their JSON type. >=20 > TODO Should we map all the integer types to just int? So, given the discussion on v3, I think we will have consensus if v5 does the following: - Merge 30 and 31 into a single patch, and drop this TODO statement (I think we have agreement that exposing QMP [that is, JSON number] wire form, with no additional constraints, as a single 'int', rather than the underlying generated C types, is the way to go), provided that... - Document in the qapi side that the schema intentionally lacks details on ranges, and that consulting the qapi and/or C code may be required to see what actual values are valid anywhere introspection merely says 'int'= , - leave 32 as a separate patch, as it is complex enough, and still may have debate on whether the types '123' and 'int' should have corresponding array types '[123]' and '[int]' rather than the v3 patch munging of '456' and '789' (I haven't yet reviewed whether v4 changed tha= t). Any further arguments on whether exposing just 'int' in the introspection for all integral types, and/or whether patches 30 and 31 should be merged, are best made in response to this mail. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --S7xABM9k3ANwQgcVxdiD66FT6dnVOfoI3 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/ iQEcBAEBCAAGBQJV6LKIAAoJEKeha0olJ0NqFH8H/Atc9JtZQE7jeoAlYPLskVX9 vxo55R4oz0hSYBiWPDlhu4M/fXZSAU+CLCNIIr8VcY8b3/ooqETHmnx7pLDRUz7J 9/EyGHRKGLz+4Bpnyr/wh4tLWry3sfAEvxLZwI1v4Lbj5DpBNRIUf9NoYaOklRYf i/Xpc0oSHw4RPMHke19XajE1lKLzOme1l7YM5V78o7ruhv1Mlq1AY+iVjVT7UCg9 vobonF4oEKiniQLf+l67+sZzohKVKSmmAzRcVuqQuJiYfT99NSRStKPbifnzt8KT d0tUpbHXB6h8B5KpfxPMo8mgQ3OpRsbYqKMNnDiz2iUFiarxHX1XmCr4kdxgnMA= =klqp -----END PGP SIGNATURE----- --S7xABM9k3ANwQgcVxdiD66FT6dnVOfoI3--