From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36696) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7wAh-0004SG-9H for qemu-devel@nongnu.org; Mon, 27 Jan 2014 19:05:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7wAa-00061V-VF for qemu-devel@nongnu.org; Mon, 27 Jan 2014 19:04:55 -0500 Received: from paradis.irqsave.net ([62.212.105.220]:48481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7wAa-00061H-5M for qemu-devel@nongnu.org; Mon, 27 Jan 2014 19:04:48 -0500 Date: Tue, 28 Jan 2014 01:04:44 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140128000444.GA3085@irqsave.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <52E6AF7F.90000@redhat.com> 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: Max Reitz Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , Kevin Wolf , famz@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, stefanha@redhat.com 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 0= 71, > >>>>>which would have to be adapted. > >>>>> > >>>>>However, first of all I'd like to hear the opinions of at least Er= ic and > >>>>>Max on what BlockRef should really refer to. I think node names ma= ke > >>>>>most sense, but perhaps it's a bit inconvenient and the command li= ne > >>>>>should default to node-name =3D id when id is set, but node-name i= sn'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 fre= edom > >>>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 manage= ment > >>>tool that wants to use the node name needs to check first if it's no= t > >>>already used as a device name somewhere else and would therefore ope= rate > >>>on the wrong device. > >>> > >>>On the other hand, a management tool using the same names for device= s > >>>and nodes just gets what it deserves. > >>> > >>>Perhaps we should use a common namespace for both, i.e. you get an e= rror > >>>if you try to assign a node name that is already a device name and v= ice > >>>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 >=20 > My only problem is that I don't really know what IDs are for, then. ;-) >=20 >>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 ? Best regards Beno=C3=AEt > Currently, I think using the node name is probably (more) correct > and it can't hurt anyone; thus, I'm okay with this patch. >=20 > Max