From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAG4R-0008MP-Qk for qemu-devel@nongnu.org; Mon, 03 Feb 2014 04:44:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAG4M-0006ix-Ox for qemu-devel@nongnu.org; Mon, 03 Feb 2014 04:44:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAG4M-0006in-Gh for qemu-devel@nongnu.org; Mon, 03 Feb 2014 04:43:58 -0500 Date: Mon, 3 Feb 2014 10:43:53 +0100 From: Kevin Wolf Message-ID: <20140203094353.GD3643@dhcp-200-207.str.redhat.com> References: <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> <52EC0862.90401@redhat.com> <20140131213700.GB3072@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140131213700.GB3072@irqsave.net> 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: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: famz@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, Max Reitz Am 31.01.2014 um 22:37 hat Beno=C3=AEt Canet geschrieben: > Le Friday 31 Jan 2014 =C3=A0 21:32:34 (+0100), Max Reitz a =C3=A9crit : > > 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=A9cri= t : > > >>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=A9c= rit : > > >>>>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 ca= se 071, > > >>>>>>>which would have to be adapted. > > >>>>>>> > > >>>>>>>However, first of all I'd like to hear the opinions of at leas= t Eric and > > >>>>>>>Max on what BlockRef should really refer to. I think node name= s make > > >>>>>>>most sense, but perhaps it's a bit inconvenient and the comman= d line > > >>>>>>>should default to node-name =3D id when id is set, but node-na= me isn't? > > >>>>>>The QAPI schema is pretty clear about this: =E2=80=9Creferences= the 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= 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 ma= nagement > > >>>>>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 de= vices > > >>>>>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 a= nd vice > > >>>>>versa? > > >>>>This is what I would go for. However, then I don't really know wh= y > > >>>>we should separate the ID and the node name in the first place > > >>>>(although that's probably because I haven't followed the discussi= on > > >>>>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 bd= s and > > >node-name naming all the bds burried in the graph. > > > > > >So my personal opinion would be to relax the constraint on bdrv_look= up_bs > > >and use it for references. > > > > > >Kevin && Max: what do you think of this scheme ? > >=20 > > 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. >=20 > Ok I will write patch doing this on top of quorum patches. Yes, I think allowing bdrv_lookup_bs() to find both node names and device names makes sense. I would still use a common namespace and forbid using the same name for a device and a node. Kevin