From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeUf8-0007mQ-JS for qemu-devel@nongnu.org; Thu, 07 Nov 2013 13:50:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeUf0-0002Yr-Rg for qemu-devel@nongnu.org; Thu, 07 Nov 2013 13:50:38 -0500 Received: from nodalink.pck.nerim.net ([62.212.105.220]:42046 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeUf0-0002Yd-B9 for qemu-devel@nongnu.org; Thu, 07 Nov 2013 13:50:30 -0500 Date: Thu, 7 Nov 2013 19:50:26 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20131107185025.GD2921@irqsave.net> References: <20131028154038.GG2890@irqsave.net> <87eh72eumr.fsf@blackfin.pond.sub.org> <20131104093155.GA3991@stefanha-thinkpad.redhat.com> <52776D51.5040305@redhat.com> <20131104110614.GC4199@dhcp-200-207.str.redhat.com> <52778601.70501@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <52778601.70501@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] How to introduce bs->node_name ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , =?iso-8859-1?Q?Beno=EEt?= Canet , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Stefan Hajnoczi Le Monday 04 Nov 2013 =E0 19:33:21 (+0800), Fam Zheng a =E9crit : >=20 > On 11/04/2013 07:06 PM, Kevin Wolf wrote: > >Am 04.11.2013 um 10:48 hat Fam Zheng geschrieben: > >>On 11/04/2013 05:31 PM, Stefan Hajnoczi wrote: > >>>On Wed, Oct 30, 2013 at 02:49:32PM +0100, Markus Armbruster wrote: > >>>>The first proposal is to add another parameter, say "id". Users ca= n > >>>>then refer either to an arbitrary BDS by "id", or (for backward > >>>>compatibility) to the root BDS by "device". When the code sees > >>>>"device", it'll look up the BB, then fetch its root BDS. > >>>> > >>>>CON: Existing parameter "device" becomes compatibility cruft. > >>>> > >>>>PRO: Clean and obvious semantics (in my opinion). > >>>This proposal gets my vote. > >>> > >>>>The second proposal is to press the existing parameter "device" int= o > >>>>service for referring to BDS node_name. > >>>> > >>>>To keep backward compatibility, we obviously need to ensure that > >>>>whenever the old code accepts a value of "device", the new code acc= epts > >>>>it as well, and both resolve it to the same BDS. > >>>Different legacy commands given the same device name might need to > >>>operate on different nodes. > >>Could you give an example for this? > >> > >> > >>>Dynamic renaming does not solve this > >>>problem, so I'm not convinced we can always choose a device name > >>>matching a node name. > >>> > >>>Device name commands are higher-level than graph node commands. For > >>>example, block_set_io_throttle makes sense on a device but less sens= e on > >>>a graph node, unless we add the implicit assumption that the new > >>>throttling node is created on top of the given node or updated in pl= ace > >>>if the throttling node already exists (!!). > >>Throttling a node could be useful too, for example if we want to > >>throttle backing_hd which is on shared storage, but not to throttle > >>on the local image. > >> > >>My ignorant question is: Why can't we just use one namespace, make > >>sure no name collision between node_name and device_name, or even > >>just drop device_name, so we treat the root node's node_name as > >>device_name? For commands that only accept a device, this can be > >>enforced in its implementation by checking against the whole graph > >>to verify this. > >Markus described it somewhere in this thread: Live snapshots. > >Currently, the device_name moves to the new BDS on the top (and > >compatibility requires us to keep it that way), whereas a node name > >should, of course, stay at its node. > > > >When you consider this, the single namespace, as much as I would have > >loved it, is pretty much dead. Good everyone agree on the direction to take. I'll write some code. Best regards Beno=EEt >=20 > Thanks for explaining (again). I get the reason now. >=20 > Fam >=20