Re: [Qemu-devel] How to introduce bs->node_name ?

[Fam Zheng <famz@redhat.com>]

On 11/04/2013 05:31 PM, Stefan Hajnoczi wrote:
> On Wed, Oct 30, 2013 at 02:49:32PM +0100, Markus Armbruster wrote:
>> The first proposal is to add another parameter, say "id".  Users can
>> then refer either to an arbitrary BDS by "id", or (for backward
>> compatibility) to the root BDS by "device".  When the code sees
>> "device", it'll look up the BB, then fetch its root BDS.
>>
>> CON: Existing parameter "device" becomes compatibility cruft.
>>
>> PRO: Clean and obvious semantics (in my opinion).
> This proposal gets my vote.
>
>> The second proposal is to press the existing parameter "device" into
>> service for referring to BDS node_name.
>>
>> To keep backward compatibility, we obviously need to ensure that
>> whenever the old code accepts a value of "device", the new code accepts
>> it as well, and both resolve it to the same BDS.
> Different legacy commands given the same device name might need to
> operate on different nodes.
Could you give an example for this?


> Dynamic renaming does not solve this
> problem, so I'm not convinced we can always choose a device name
> matching a node name.
>
> Device name commands are higher-level than graph node commands.  For
> example, block_set_io_throttle makes sense on a device but less sense on
> a graph node, unless we add the implicit assumption that the new
> throttling node is created on top of the given node or updated in place
> if the throttling node already exists (!!).
Throttling a node could be useful too, for example if we want to 
throttle backing_hd which is on shared storage, but not to throttle on 
the local image.

My ignorant question is: Why can't we just use one namespace, make sure 
no name collision between node_name and device_name, or even just drop 
device_name, so we treat the root node's node_name as device_name? For 
commands that only accept a device, this can be enforced in its 
implementation by checking against the whole graph to verify this.

Fam