From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfWKW-0004q2-3J for qemu-devel@nongnu.org; Thu, 23 May 2013 10:17:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfWKS-0007zR-O5 for qemu-devel@nongnu.org; Thu, 23 May 2013 10:17:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfWKS-0007z9-Ez for qemu-devel@nongnu.org; Thu, 23 May 2013 10:17:16 -0400 Message-ID: <519E24E9.2020800@redhat.com> Date: Thu, 23 May 2013 08:17:13 -0600 From: Eric Blake MIME-Version: 1.0 References: <20130522134007.GA2051@t430s.nay.redhat.com> <20130522144448.GC23852@dhcp-200-207.str.redhat.com> <87fvxfkn49.fsf@codemonkey.ws> <20130523081837.GA3082@dhcp-200-207.str.redhat.com> <87a9nlx5ic.fsf@codemonkey.ws> <20130523125400.GD3082@dhcp-200-207.str.redhat.com> <87wqqpdcr0.fsf@codemonkey.ws> In-Reply-To: <87wqqpdcr0.fsf@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2IICKCRHQTNKIGLJQEMXU" Subject: Re: [Qemu-devel] RFC: Full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Markus Armbruster , qemu-devel , lcapitulino@redhat.com, Ronen Hod , Amos Kong This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IICKCRHQTNKIGLJQEMXU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/23/2013 07:52 AM, Anthony Liguori wrote: >> libvirt already knows how to use features. It must know it, just parsi= ng >> the schema doesn't automagically give you libvirt code, so someone mus= t >> have coded the libvirt side of things. The interesting part is whether= a >> given interface is available on this specific qemu binary. >=20 > Take 'drive-mirror' as an example. The format parameter is a string. > You can't tell what valid arguments are for this parameter with > introspection. >=20 > You can certainly say that we can make this an enum, and do > introspection on the enums, but that only works because it's a string. Introspection on an enum and on optional parameters are both nice ways of learning whether libvirt can expect success when passing a particular use of that enum or option extension. That does not cover ALL ways that features are added, but it sure covers a lot, which makes it a nice reusable framework for learning about quite a few features. Yes, I suspect we will still have to add some query-* commands along the way for features that aren't quite discernible solely from introspection, or even where a query can give the information in a nicer format than crawling through several layers of type information, but I see these as orthogonal, not competing, so that is not a reason to exclude either approach from being added to QMP. >=20 > The same thing can apply to integer arguments. If a new value becomes > valid that previously was rejected, then libvirt probably needs to be > able to figure that out. Changing an integer range is a bit harder; but again, with PROPER introspection, you can include range information alongside type informati= on. >=20 >>>> It also makes the schema totally useless. If you can't use it to tel= l >>>> which commands this qemu can execute and which it can't, >>> >>> query-commands serves that purpose. >> >> It solves a subset of this problem. Optional fields can be added as >> arguments or to returned structs, enums can be extended, and so far >> we're having a hard time making use of it because the client can't >> discover it. >=20 > Ack. Yes, this is the primary motivating factor behind asking for introspection at the moment. >=20 >>>> We can have hundreds of individual query commands like you suggest >>>> (query-qcow2-creation-option-values, yay!) or we do the modularity >>>> thing and the schema introspection properly and make it dynamic. I >>>> prefer the latter. >>> >>> Let's consider a real example. It sounds like you have something in >>> mind, can you be more specific? >> >> Not a very specific one, it's just that the more I discuss about thing= s >> like blockdev-add, the more I get the impression that there is an awfu= l >> lot of information to query. Each image format can provide different >> options, for creating images and for opening them, and some of them ma= y >> be enums that could be extended and whose values must be queried etc. >=20 > But is this specific to blockdev-add? The supported image formats are > global and apply to multiple commands. >=20 But that still argues that having a dynamic approach to learning "what formats are supported, and what options does a given format provide beyond the basics". > Also, do we need to expose which formats are read-only vs. read-write? > That wouldn't be part of the schema I would think. True, a pure 'enum' in qapi-schema.json wouldn't expose which types are read-only vs. read-write, so that argues for a query-* command for learning details about the various block formats. Once you have a query-* command (which is dynamic), then having a non-dynamic 'enum' in the schema expressing all known types (whether loaded or not) is reasonable, where the query command then returns the subset of known formats that are actually loaded and what additional features each format comes with. >=20 >> Schema introspection allows you to have one single way to check for al= l >> optional fields, enum values, union branches. The other way is to have= a >> separate command for each of them. >=20 > Yes, my only worry is that the schema probably doesn't contain all of > the information that something like libvirt needs. I don't think that schema introspection can provide everything, but it can sure provide a lot, and minimize the number of cases where we actually need a query-* command. >=20 >> Basically instead of query-enum(Qcow2PreallocationType) you get >> query-qcow2-prellocation-types(). You can imagine how the set of >> commands grows once you start doing things this way. >> >> When I discussed with Eric (who is one of the few actual consumers of >> the API), he preferred introspection of a dynamic schema as well, >> compared to many separate query-* commands. >=20 > I'm not opposed to schema introspection even if it's used for this type= > of use-case. >=20 > But I don't think it's a complete solution. We should think about what= > the use-cases are and make sure we have a solution that addresses them.= Agreed. >=20 > None of that should hold back schema introspection... Agreed. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2IICKCRHQTNKIGLJQEMXU 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.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRniTpAAoJEKeha0olJ0Nq+EYIAJ7zuQ02nNk6/k2Je7GboKv9 x1efqPc1Ye/8vXB7P10W//l6p2fnKNR4ekHIdUeouU9Wt7yOgm86tt/w8ubZcqhV z93PKyBp7yWZqe3aqXUkCNRrRvzjBk4oXUlb2UPpfUtCFr8pP0CJQe3P4YYovXlQ GFRowlwifeqab8W1PpWNznBnj1gGl1XhmNw+1ZMXm35GOCYY9ip3CLjWz5QK1MB8 qpvNAlhuG24FSHmjekr1/VCLLM2cL945QTiWRJ/aXzwYQdftUQ9a10YTRsqW/5gX Bh1lcKy2wGWJG8CRjswEs4cW2uO4W0u6RphPU4YzFoVfIpgzMfEZuZEnNt8Yy8k= =NQUE -----END PGP SIGNATURE----- ------enig2IICKCRHQTNKIGLJQEMXU--