Kevin Wolf <kw...@redhat.com> writes: > Am 05.12.2014 um 10:34 hat Markus Armbruster geschrieben: >> Eric Blake <ebl...@redhat.com> 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.
We have query-commands. Lets you check for presence of commands, but no more. >> > 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. Yes, but you only have to probe for "parameter is accepted", and not for "parameter is accepted and both backend and node names work". > But as long as libvirt doesn't support the node-name interface yet > anyway, I think this discussion is mostly moot. Tend to agree for this specific instance.
