From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdIPX-0006RK-Gj for qemu-devel@nongnu.org; Mon, 04 Nov 2013 06:33:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdIPR-0004UU-I4 for qemu-devel@nongnu.org; Mon, 04 Nov 2013 06:33:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdIPR-0004UP-8d for qemu-devel@nongnu.org; Mon, 04 Nov 2013 06:33:29 -0500 Message-ID: <52778601.70501@redhat.com> Date: Mon, 04 Nov 2013 19:33:21 +0800 From: Fam Zheng MIME-Version: 1.0 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> In-Reply-To: <20131104110614.GC4199@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] How to introduce bs->node_name ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: =?ISO-8859-1?Q?Beno=EEt_Canet?= , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi , Luiz Capitulino 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 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. Thanks for explaining (again). I get the reason now. Fam