From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdGlf-0008Fd-9V for qemu-devel@nongnu.org; Mon, 04 Nov 2013 04:48:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdGlZ-00039n-AG for qemu-devel@nongnu.org; Mon, 04 Nov 2013 04:48:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:11089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdGlZ-00039f-2O for qemu-devel@nongnu.org; Mon, 04 Nov 2013 04:48:13 -0500 Message-ID: <52776D51.5040305@redhat.com> Date: Mon, 04 Nov 2013 17:48:01 +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> In-Reply-To: <20131104093155.GA3991@stefanha-thinkpad.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: Stefan Hajnoczi , Markus Armbruster Cc: =?ISO-8859-1?Q?Beno=EEt_Canet?= , kwolf@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino 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. Fam