From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfVxL-0002Q8-Fz for qemu-devel@nongnu.org; Thu, 23 May 2013 09:53:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UfVxG-0006FD-01 for qemu-devel@nongnu.org; Thu, 23 May 2013 09:53:23 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:39623) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UfVxF-0006EL-Du for qemu-devel@nongnu.org; Thu, 23 May 2013 09:53:17 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 May 2013 23:50:37 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id 25113357804A for ; Thu, 23 May 2013 23:53:05 +1000 (EST) Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4NDqvUG21758052 for ; Thu, 23 May 2013 23:52:57 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4NDr4U1016479 for ; Thu, 23 May 2013 23:53:04 +1000 From: Anthony Liguori In-Reply-To: <20130523125400.GD3082@dhcp-200-207.str.redhat.com> 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> Date: Thu, 23 May 2013 08:52:51 -0500 Message-ID: <87wqqpdcr0.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] RFC: Full introspection support for QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel , Amos Kong , Markus Armbruster , Ronen Hod , lcapitulino@redhat.com Kevin Wolf writes: > Am 23.05.2013 um 14:08 hat Anthony Liguori geschrieben: >> Kevin Wolf writes: >> >> >> There are two things here: the schema and the generated code. The >> generated code can and should live in the module. >> >> But the schema always stays the same. >> >> Think of the schema like kernel headers. The kernel headers are always >> fixed regardless of what kernel modules are loaded or how the kernel is >> configured. >> >> > then we don't need introspection at all. There's no user for it then. >> >> Introspection is not the right approach to feature discovery. The >> schema does answer the question of what features are enabled, it just >> answers the question of what the signature of the methods are. > > You can see it like this. Then, as I said, it's totally useless, It's not totally useless. It's impossible to write a reasonable python client for QMP because arguments are not ordered (they are always named). So you can't have: qmp.block_commit('ide0-hd0', ...) You have to have: qmp.block_commit(device='ide0-hd0', ...) Which is a little less nice. The schema introspection solves this but I agree, it's not a critical problem to solve. > because nobody has ever asked this question. The context in which > libvirt wants to use it is feature discovery. If we don't support > that, then there's no reason to provide introspection at all. > > libvirt already knows how to use features. It must know it, just parsing > the schema doesn't automagically give you libvirt code, so someone must > have coded the libvirt side of things. The interesting part is whether a > given interface is available on this specific qemu binary. 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. 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. 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. >> > It also makes the schema totally useless. If you can't use it to tell >> > 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. Ack. >> > 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 things > like blockdev-add, the more I get the impression that there is an awful > lot of information to query. Each image format can provide different > options, for creating images and for opening them, and some of them may > be enums that could be extended and whose values must be queried etc. But is this specific to blockdev-add? The supported image formats are global and apply to multiple commands. 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. > Schema introspection allows you to have one single way to check for all > optional fields, enum values, union branches. The other way is to have a > separate command for each of them. Yes, my only worry is that the schema probably doesn't contain all of the information that something like libvirt needs. > 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. I'm not opposed to schema introspection even if it's used for this type of use-case. 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. None of that should hold back schema introspection... Regards, Anthony Liguori > > Kevin