From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwpTg-0007Oc-PG for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:47:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwpTa-00023j-KC for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:47:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwpTa-00023f-Cl for qemu-devel@nongnu.org; Fri, 05 Dec 2014 04:47:02 -0500 Date: Fri, 5 Dec 2014 10:46:56 +0100 From: Kevin Wolf Message-ID: <20141205094656.GA6040@noname.str.redhat.com> References: <87vbltvpl0.fsf@blackfin.pond.sub.org> <20141203103041.GB4404@noname.str.redhat.com> <87k327e7dp.fsf@blackfin.pond.sub.org> <5480B985.4050708@redhat.com> <87vblq30e8.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vblq30e8.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] Review of monitor commands identifying BDS / BB by name List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Fam Zheng , jcody@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, Stefan Hajnoczi , benoit.canet@nodalink.com Am 05.12.2014 um 10:34 hat Markus Armbruster geschrieben: > Eric Blake writes: > > > On 12/04/2014 08:56 AM, Markus Armbruster wrote: > > > >> > >> @device is a sub-optimal name for this single parameter. Either we > >> accept that and move on, or we deprecate it in favor of a new parameter > >> with a better name. I guess the better name isn't worth that much > >> trouble, in particular since the command name is already ugly. > >> > >> When @node-name is given, @device must not be given. So @device is > >> mandatory *except* in the @node-name usage we retain for compatibility. > >> Deprecate the usage. > >> > >> Command documentation could then look like this: > >> > >> ## > >> # @block-resize > >> # > >> # Resize a block image while a guest is running. > >> # > >> # @device: the name of the block backend or node to resize (node names > >> # supported since 2.3) > >> # > >> # @size: new image size in bytes > >> # > >> # Deprecated usage (since 2.3): > >> # > >> # @device: #optional the name of the block backend to resize > >> # > >> # @node-name: #optional name of the node to resize (since 2.0) > >> # > >> # Either @device or @node-name must be set but not both. > > > > But this isn't discoverable. You aren't changing whether any parameters > > are optional, only enhancing the semantics of existing parameters. How > > is libvirt supposed to know if qemu is old (node names have to go > > through node-name) or new (node names are preferred through device)? > > Good point. > > > Just blindly try the 'device' argument, and if it fails, fall back to an > > attempt with node-name? > > Works, but "try interfaces one after the other until you find one that > works" is a rather lame discovery technique. As long as we don't have introspection, it's the only one we have. > > On the other hand, if 'node-name' becomes the preferred interface, then > > libvirt has a solution: if node-name is present (it is easy during > > up-front QMP probing to determine whether 'node-name' is a recognized > > optional argument or an unknown argument), then always use node-name. > > As long as libvirt always names the nodes of each device (which it > > should be doing, but that's a patch series for another day and another > > list), then a device lookup is never needed. If 'node-name' is not > > present, then only the 'device' form is supported, and libvirt can only > > manage the top image of a backend (but can make that point obvious to > > the end user that they should upgrade qemu for more functionality). > > If we deprecate @device instead of @node-name, we make the appropriate > (non-deprecated) use of backend names rather than node names hard to > probe. > > Command argument introspection could help only if it carried > "deprecated" flags. Might be a good idea anyway, but command > introspection is one of those nice-to-haves we can't seem to deliver. > > A possible alternative is our common way to cheat at probing: when > probing for A is hard, probe for B, and assume support for B implies > support for A. > > My guess that a "better name [than @device for the single parameter] > isn't worth that much trouble" needs to be reevaluated with > discoverability in mind. Yes, it's troublesome, but it's also easily > discoverable. Still requires trying the new argument and then falling back to @device/ @node-name. But as long as libvirt doesn't support the node-name interface yet anyway, I think this discussion is mostly moot. Kevin