Re: [Qemu-devel] Can we make monitor commands identify BDS / BB by name consistently?

[Markus Armbruster <armbru@redhat.com>]

Markus Armbruster <armbru@redhat.com> writes:

> Conscious design decision: Backend (BB) and node (BDS) names share a
> common name space.
>
> Enables a convenience feature: when a command needs a node, we accept
> either kind of name, and a backend name is resolved to its root node.
>
> Should not be confused with a command that can work either on a backend
> or on a node.  There, a backend name resolves to the backend, not its
> root node.  Can't point to an example offhand.
>
> Let's concentrate on the "command needs a node" case.
>
> As we saw in my review of monitor commands, we have two different
> conventions there.
>
> * Single name
>
>   Within BlockdevOptions objects (used by blockdev-add), we use a single
>   string member, with a name that explains its role.  Actually, the
>   member is an anonymous union of string and BlockdevOptions.
>
>   Example: a BlockdevOptionsGenericFormat object (used for format "raw"
>   and others) has a member @file that may name a backend or a node.
>
>   Example: a BlockdevOptionsQcow2 object (used for "qcow2"), has a
>   member @file as above, and a member @backing that may again name a
>   backend or a node.
>
> * Pair of names
>
>   Elsewhere, command argument objects have a pair of optional members,
>   of which exactly one must be present.  One of them must name a
>   backend, the other must name a node.  The former is commonly called
>   @device, the latter @node-name.
>
>   Example: block_passwd parameters @device and @node-name.
>
> I'd very much like some consistency here.
>
> As Kevin pointed out, you can't easily change BlockdevOptions to the
> "pair of names" convention, because an anonymous union can have only one
> object member, and that's taken by BlockdevOptions.  If you want us to
> adopt the "pair of names" convention, you need to come up with a way to
> use it with BlockdevOptions.
>
> I want us to adopt the "single name" convention instead.  Therefore, I
> need to come up with a way to use it with the command argument objects
> that currently use "pair of names".  The problems there are
> compatibility and discoverability.
[Text on how to solve them snipped...]

John Snow pointed out to me that we still haven't spelled out how this
single parameter should be named.

On obvious option is calling it node-name, or FOO-node-name when we have
several.  However, we'd then have two subtly different kinds of
parameters called like that: the old ones accept *only* node names, the
new ones also accept backend names, which automatically resolve to the
backend's root node.

Three ways to cope with that:

* Find a better name.

* Make the old ones accept backend names, too.  Only a few, not that
  much work.  However, there are exceptions:

  - blockdev-add's node-name *defines* the node name.

  - query-named-block-nodes's node-name *is* the node's name.

* Stop worrying and embrace the inconsistency.  The affected commands
  are headed for deprecation anyway.

I think I'd go with "node" or "FOO-node" for parameters that reference
nodes and accept both node names and backend names, and refrain from
touching the existing node-name parameters.

Opinions?