From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40758) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9KjT-0005LR-Tn for qemu-devel@nongnu.org; Fri, 31 Jan 2014 15:30:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9KjO-0006WM-Le for qemu-devel@nongnu.org; Fri, 31 Jan 2014 15:30:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9KjO-0006VR-6W for qemu-devel@nongnu.org; Fri, 31 Jan 2014 15:30:30 -0500 Message-ID: <52EC0862.90401@redhat.com> Date: Fri, 31 Jan 2014 21:32:34 +0100 From: Max Reitz MIME-Version: 1.0 References: <1390509099-695-1-git-send-email-benoit.canet@irqsave.net> <1390509099-695-9-git-send-email-benoit.canet@irqsave.net> <20140124132619.GF3342@dhcp-200-207.str.redhat.com> <52E26C98.1070206@redhat.com> <20140124144854.GI3342@dhcp-200-207.str.redhat.com> <52E27EAF.7020209@redhat.com> <20140127143644.GH7415@irqsave.net> <52E6AF7F.90000@redhat.com> <20140128000444.GA3085@irqsave.net> In-Reply-To: <20140128000444.GA3085@irqsave.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V6 8/8] block: Use graph node name as reference in bdrv_file_open(). List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= Cc: Kevin Wolf , famz@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, stefanha@redhat.com On 28.01.2014 01:04, Beno=C3=AEt Canet wrote: > Le Monday 27 Jan 2014 =C3=A0 20:11:59 (+0100), Max Reitz a =C3=A9crit : >> On 27.01.2014 15:36, Beno=C3=AEt Canet wrote: >>> Le Friday 24 Jan 2014 =C3=A0 15:54:39 (+0100), Max Reitz a =C3=A9crit= : >>>> 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=C3=AEt Canet geschrieben: >>>>>>>> Signed-off-by: Benoit Canet >>>>>>>> --- >>>>>>>> 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 E= ric and >>>>>>> Max on what BlockRef should really refer to. I think node names m= ake >>>>>>> most sense, but perhaps it's a bit inconvenient and the command l= ine >>>>>>> should default to node-name =3D id when id is set, but node-name = isn't? >>>>>> The QAPI schema is pretty clear about this: =E2=80=9Creferences th= e ID of an >>>>>> existing block device.=E2=80=9D >>>>> 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 fr= eedom >>>>> 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 manag= ement >>>>> tool that wants to use the node name needs to check first if it's n= ot >>>>> already used as a device name somewhere else and would therefore op= erate >>>>> on the wrong device. >>>>> >>>>> On the other hand, a management tool using the same names for devic= es >>>>> 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=C3=AEt >> 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 a= nd > 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=20 only if both ID and node name are actually valid (and point to different=20 devices), that is, bdrv_find() and bdrv_find_node() return different=20 non-NULL values. Max