From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwrw1-0006U6-4h for qemu-devel@nongnu.org; Thu, 12 Nov 2015 08:29:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwrvx-0000Oh-UL for qemu-devel@nongnu.org; Thu, 12 Nov 2015 08:29:05 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35315) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwrvx-0000Ob-MW for qemu-devel@nongnu.org; Thu, 12 Nov 2015 08:29:01 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 9BB6D263A for ; Thu, 12 Nov 2015 13:29:00 +0000 (UTC) References: <1447291062-11011-1-git-send-email-eblake@redhat.com> <8737wbtrwq.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <5644941B.9000608@redhat.com> Date: Thu, 12 Nov 2015 06:28:59 -0700 MIME-Version: 1.0 In-Reply-To: <8737wbtrwq.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eNMNVs6g0vUwJdw5fgFBWULQcUVcMIe44" Subject: Re: [Qemu-devel] [PATCH for-2.5 0/4] Expose ErrorClass through introspection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eNMNVs6g0vUwJdw5fgFBWULQcUVcMIe44 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/12/2015 03:48 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> I noticed that introspection was not documenting either >> qmp_capabilities nor the ErrorClass enum. I think this is worth >> fixing for 2.5 when introspection is brand new, so that if we later >> extend the ErrorClass enum or add future capability negotiation (and >> in particular if such additions get backported in downstream builds), >> a client will be able to use introspection to learn whether the new >> features are supported, regardless of the qemu version. >> >> Note that this also adds qmp_capabilities to 'query-commands'. >> >> Yes, this is borderline, and you may decide that it doesn't deserve >> to be called a bug and should wait for 2.6. Or in other words, I posted this series precisely for this conversation. The mere fact that you have questions means that it is NOT appropriate for 2.5 this late in the game. But to answer you... >=20 > Two entirely separate issues: introspecting qmp_capabilities and > introspecting error classes. This reply is about the former. I'll > discuss the latter in a separate message. >=20 > Introspecting qmp_capabilities with query-qmp-schema is kind of > academic, because by the time you can query-qmp-schema, you're already > done using qmp_capabilities. That's why docs/qmp-spec.txt nails down > qmp_capabilities, unlike other commands. Unfortunately, it's a bit > screwy. Let's have a closer look. >=20 > Right after connect, the server sends a greeting that includes a list o= f > available capabilities (docs/qmp-spec.txt section 2.2 Server Greeting),= > currently none. >=20 > The only valid command then is qmp_capabilities (section 4. Capabilitie= s > Negotiation). The command is meant to let clients enable capabilities > from the greeting, but we've neglected to specify how. Fortunately, QM= P > rejects all arguments, so we can still fix that by adding optional > arguments, either a list of capabilities to enable, or a (boolean) > argument for each capability. >=20 > My point is: unlike other commands, qmp_capabilities is baked into the > protocol. Introspection is useful to examine *variable* aspects. With= > the hole in the protocol specification plugged, the only variable aspec= t > of qmp_capabilities are the capabilities, and the practical way to > introspect those is the server greeting. Good point - if we ever add a capability, a client that knows how to request the capability can easily learn whether the server will honor the request by reading the server's advertisements. >=20 > Qapifying qmp_capabilities can make sense regardless. But why does it > need to be rushed into 2.5 then? No need for the rush after all. You are correct that qapi-fying qmp_capabilities will NOT help the client learn anything it couldn't have already learned from the server greeting. And if we don't rush qmp_capabilities into 2.5 (patch 3), then we also don't need to rush in a fix for explicitly empty types (patch 2) or a way to detect empty types (patch 1). As for patch 4 - we could still expose ErrorClass, via some means other than qmp_capabilities, if desired; but that's a discussion for your other mail. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --eNMNVs6g0vUwJdw5fgFBWULQcUVcMIe44 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/ iQEcBAEBCAAGBQJWRJQbAAoJEKeha0olJ0Nq/gkH/iOLXhWD3F8nMUqnMgPOjvoD Uq96jOZ66IxYOSwkVbK6N+axF6SOkO1wq3L6mX9tEGUgOkx2P3dqbGIJ4S9xJLdR QCx9+JYgrDXzx/Idwb7Podx3qQSxupVOtP5kuVIrPsr9r6PAX6re7kEqmGUQrxbN +y8YbMBrIlI2ChbnoudrITnlFo6giP3+XO+fbH/vpwnzkTjZS224FOuuzkncxsFg DDXQ8jgaHK9jwa1wEZtjxlyV5eAv6WbQG21Hirby3L8WyS1BFSPmoHlphiGImThv JB0dvVL6kESfmV0V8h2M0oz05YvqfGe96rlfDzYZvHGb04+U2O19epgn3QMduNY= =7dG8 -----END PGP SIGNATURE----- --eNMNVs6g0vUwJdw5fgFBWULQcUVcMIe44--