From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdHzK-0000LY-M8 for qemu-devel@nongnu.org; Mon, 04 Nov 2013 06:06:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdHzE-00065k-Bd for qemu-devel@nongnu.org; Mon, 04 Nov 2013 06:06:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16995) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdHzE-00063f-3i for qemu-devel@nongnu.org; Mon, 04 Nov 2013 06:06:24 -0500 Date: Mon, 4 Nov 2013 12:06:14 +0100 From: Kevin Wolf Message-ID: <20131104110614.GC4199@dhcp-200-207.str.redhat.com> References: <20131028154038.GG2890@irqsave.net> <87eh72eumr.fsf@blackfin.pond.sub.org> <20131104093155.GA3991@stefanha-thinkpad.redhat.com> <52776D51.5040305@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52776D51.5040305@redhat.com> 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: =?iso-8859-1?Q?Beno=EEt?= Canet , Luiz Capitulino , Markus Armbruster , Stefan Hajnoczi , qemu-devel@nongnu.org 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 can > >>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" into > >>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 accepts > >>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 sense 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 place > >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. Kevin