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, 24 Jan 2014 15:54:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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



reply via email to

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