From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYnXS-0005u9-WB for qemu-devel@nongnu.org; Sun, 06 Sep 2015 23:56:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYnXR-0004Pz-L6 for qemu-devel@nongnu.org; Sun, 06 Sep 2015 23:56:14 -0400 References: <1439279489-13338-1-git-send-email-wency@cn.fujitsu.com> <1439279489-13338-6-git-send-email-wency@cn.fujitsu.com> <55E4A536.6040905@redhat.com> <55E4F767.1070602@cn.fujitsu.com> <55E5C572.7000606@redhat.com> <55E65026.2050902@cn.fujitsu.com> <55E70F26.8020506@redhat.com> From: Wen Congyang Message-ID: <55ED0ABD.2030204@cn.fujitsu.com> Date: Mon, 7 Sep 2015 11:55:41 +0800 MIME-Version: 1.0 In-Reply-To: <55E70F26.8020506@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Patch for-2.5 v2 5/6] qmp: add monitor command to add/remove a child List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu devel , Markus Armbruster , Alberto Garcia , Stefan Hajnoczi Cc: Kevin Wolf , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , "Dr. David Alan Gilbert" , Max Reitz , Gonglei , Yang Hongyang On 09/02/2015 11:00 PM, Eric Blake wrote: > On 09/01/2015 07:25 PM, Wen Congyang wrote: >> On 09/01/2015 11:34 PM, Eric Blake wrote: >>> On 08/31/2015 06:55 PM, Wen Congyang wrote: >>> >>>>>> +This command is still a work in progress. It doesn't support all >>>>>> +block drivers. Stay away from it unless you want it to help with >>>>>> +its development. >>>>> >>>>> Maybe we should name it 'x-child-add' for now, so that we aren't baking >>>>> ourselves into a corner. >>>> >>>> Do you mean the command name should be x-child-add? It is OK. >>> >>> Use of the 'x-' prefix means a command is experimental and may change or >>> be withdrawn. It gives us a way to test if an interface is useful >>> without committing to that interface long term. We've still got time >>> before 2.5 to get blockdev-add working everywhere, in which case I think >>> we are better off using blockdev-add to create a new unattached BDS and >>> then have this command pass the node name to be made the new child, >>> rather than all the options for opening the child from scratch. >>> >> >> Good idea. The unattached BDS created by the command blockdev-add always >> have BB. So it may be used by the device created by the command device_add >> later. > > We recently discussed (although the current documentation of > BlockdevOptionsBase sounds like it hasn't been merged yet) the idea of > enhancing blockdev-add to control whether a BB is created alongside a BDS. > > Remember, blockdev-add can be used to create a chain. When originally > implemented, we documented that 'id' must be present on the top of the > chain, and absent everywhere else, and that 'node-name' was optional > everywhere. The 'id' became associated with the BB at the top level, > and the optional node-names allow you to then manipulate other BDS. But > the proposal at hand is that we would allow 'id' to be optional at the > top level (at which point 'node-name' is required, because we have to > have SOME way to refer to the BDS); and when that happens, we end up > creating a BDS that is not associated with any BB yet. Similarly, it is > possible to create a BB that does not yet have a BDS yet (think an empty > cdrom drive); so it then becomes possible to associate a BDS to a BB as > a separate step. > > [/me goes searching] > Ah - we are waiting for Max's patches to land: > https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg04201.html > in particular patch 02/38: > https://lists.gnu.org/archive/html/qemu-devel/2015-07/msg04204.html > > Once we have that, then we can indeed create a BDS without a BB, and it > is then that you can plug your unconnected BDS into a quorum. So I'd > recommend helping review Max's series, and base your actions on top of > his (I really do think it is a better approach to separate BDS creation > from chain manipulation, and your add/remove a child is about chain > manipulation and does not need to be creating BDS). > >> So I think we should have an API to check it. What about the following >> patches? >> http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg01591.html >> http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg01590.html > > I haven't looked at them yet, but really like Max's approach for > separating BDS from BB by treating BB without BDS as an empty media > case, and BDS without a BB as something that can then be manipulated to > be associated with another BDS or BB. Do you mean we can create a top BDS without BB by the command line -drive in the future? Thanks Wen Congyang