From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWqyy-0007ik-66 for qemu-devel@nongnu.org; Tue, 01 Sep 2015 15:12:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWqyt-0003Jz-7M for qemu-devel@nongnu.org; Tue, 01 Sep 2015 15:12:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60746) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWqys-0003Jk-Vn for qemu-devel@nongnu.org; Tue, 01 Sep 2015 15:12:31 -0400 References: <1438703896-12553-1-git-send-email-armbru@redhat.com> <1438703896-12553-31-git-send-email-armbru@redhat.com> <20150901184026.18566.39890@loki> From: Eric Blake Message-ID: <55E5F898.6040304@redhat.com> Date: Tue, 1 Sep 2015 13:12:24 -0600 MIME-Version: 1.0 In-Reply-To: <20150901184026.18566.39890@loki> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LTQP5963os9sCKIjr0pSc9uVHp969RHnM" Subject: Re: [Qemu-devel] [PATCH RFC v3 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: Michael Roth , Markus Armbruster , qemu-devel@nongnu.org Cc: kwolf@redhat.com, berto@igalia.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LTQP5963os9sCKIjr0pSc9uVHp969RHnM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/01/2015 12:40 PM, Michael Roth wrote: > Quoting Markus Armbruster (2015-08-04 10:58:14) >> Caution, rough edges. >> >> qapi/introspect.json defines the introspection schema. It should do >> for uses other than QMP. >> FIXME it's almost entirely devoid of comments. >> >> 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. >> >> Introspection lowers away a number of schema details: >> >> * The built-in types are declared with their JSON type. >> >> TODO Should we map all the integer types to just int? >=20 > I don't think we should. If management chooses to handle them in this > generic fashion that's their perogative/problem, but treating all ints > as a single generic type can lead to unexpected results when those valu= es > get passed on to functions expecting, for instance, uint8_t. So QEMU > should do its part to convey this information somehow. The argument here is that it is always more conservative to start with less information, where we can later add more information (whether in the form of type constraints such as uint8_t, or in a different form such as min/max values) if they prove useful. And QMP already guarantees that it gives sane error messages for parameters that are out of range, so the worst behavior a client might see is that a parameter claiming to be 'int' in the introspection gracefully rejects an attempt to use '256' as a value because the underlying type was uint8_t. If we advertise full types now, then the choice of integer type becomes ABI (switching from 'int8_t' to 'uint8_t' has observable impact in the introspection) that we are stuck exposing in introspection forever. And in the past, we have successfully retyped a command with no change to the wire API (see commit 5fba6c0). At any rate, patch 31/32 in this series gives stronger arguments for merging the types for at least the initial implementation; we can always change our minds later and undo the merging, even if it is after 2.5 when we change our minds. But the mere fact that you are questioning the idea means that patch 30 and 31 should not be merged (previously, I had argued that separating the patches didn't make sense; I don't know if Markus was planning to merge the two based on my recommendation), if only so that reverting the type merging becomes an easier task if we decide down the road that we don't need the merged types. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --LTQP5963os9sCKIjr0pSc9uVHp969RHnM 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/ iQEcBAEBCAAGBQJV5fiYAAoJEKeha0olJ0NqMLgH/0RfJUMxxrS7/qwfb3Axft4X cm3BLNUMX2hHNFi/5hXxgeh7FUWywbs68S+p7VHub+ZV0WD73S/qbXrHFqDHubDb PvqyI4Vw18IX1PDji4xxe8N8neZS+7HQRWrUblcSL1OLEYDxRqcPigAitzryx0si SvnRkZ6uPeLkJgRShDDKBS0R/Kk2Jeh1Ey4vUM011SXKzYPPFivOi4pHTmH0gQI5 qYz2+FJQribFCqVyEV7ly4LeMYvhDC3Wfx416RYHAJFr+shaVMj+w9+jOkWBWtp2 WjcZDvabbCKfJxMjRHBvJ/Vohsq27w/+RolSLnpr5pC/IGApei1umXouAzmmFfg= =GwXL -----END PGP SIGNATURE----- --LTQP5963os9sCKIjr0pSc9uVHp969RHnM--