qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V6 8/8] block: Use graph node name as reference


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH V6 8/8] block: Use graph node name as reference in bdrv_file_open().
Date: Fri, 31 Jan 2014 21:32:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 28.01.2014 01:04, Benoît Canet wrote:
Le Monday 27 Jan 2014 à 20:11:59 (+0100), Max Reitz a écrit :
On 27.01.2014 15:36, Benoît Canet wrote:
Le Friday 24 Jan 2014 à 15:54:39 (+0100), Max Reitz a écrit :
On 24.01.2014 15:48, Kevin Wolf wrote:
Am 24.01.2014 um 14:37 hat Max Reitz geschrieben:
On 24.01.2014 14:26, Kevin Wolf wrote:
Am 23.01.2014 um 21:31 hat Benoît Canet geschrieben:
Signed-off-by: Benoit Canet <address@hidden>
---
  block.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
I'm not going to merge this one yet. It breaks qemu-iotests case 071,
which would have to be adapted.

However, first of all I'd like to hear the opinions of at least Eric and
Max on what BlockRef should really refer to. I think node names make
most sense, but perhaps it's a bit inconvenient and the command line
should default to node-name = id when id is set, but node-name isn't?
The QAPI schema is pretty clear about this: “references the ID of an
existing block device.”
Sure, that's because I wrote that text before we had a node name.

However, in 1.7 references didn't work yet, so we still have all freedom
to change the interface as we like.
Yes, that's right.

However, if the ID cannot be found, I think
we should interpret it as a reference to the node name.

Therefore, I'd first try bdrv_find() and if that returns NULL, try
again with bdrv_find_node().
I think I would prefer to avoid such ambiguities. Otherwise a management
tool that wants to use the node name needs to check first if it's not
already used as a device name somewhere else and would therefore operate
on the wrong device.

On the other hand, a management tool using the same names for devices
and nodes just gets what it deserves.

Perhaps we should use a common namespace for both, i.e. you get an error
if you try to assign a node name that is already a device name and vice
versa?
This is what I would go for. However, then I don't really know why
we should separate the ID and the node name in the first place
(although that's probably because I haven't followed the discussion
around node names).

Max
Ping,

I still want to make quorum merge.
What should be done for the references ?

Best regards

Benoît
My only problem is that I don't really know what IDs are for, then. ;-)

 From the understanding I have ID are for block backend top level bds and
node-name naming all the bds burried in the graph.

So my personal opinion would be to relax the constraint on bdrv_lookup_bs
and use it for references.

Kevin && Max: what do you think of this scheme ?

I agree. For example, we could change the constraint to report an error only if both ID and node name are actually valid (and point to different devices), that is, bdrv_find() and bdrv_find_node() return different non-NULL values.

Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]