[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Can we make monitor commands identify BDS / BB by name
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Can we make monitor commands identify BDS / BB by name consistently? |
Date: |
Fri, 19 Dec 2014 19:27:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Markus Armbruster <address@hidden> 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?
- Re: [Qemu-devel] Review of monitor commands identifying BDS / BB by name, (continued)
[Qemu-devel] Can we make monitor commands identify BDS / BB by name consistently? (was: Review of monitor commands identifying BDS / BB by name), Markus Armbruster, 2014/12/16
[Qemu-devel] Review of ways to create BDSes (was: Review of monitor commands identifying BDS / BB by name), Markus Armbruster, 2014/12/18
[Qemu-devel] Review of ways to reopen BDSes (was: Review of monitor commands identifying BDS / BB by name), Markus Armbruster, 2014/12/19