From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX9XG-0008F6-00 for qemu-devel@nongnu.org; Wed, 02 Sep 2015 11:01:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZX9XC-0007au-9G for qemu-devel@nongnu.org; Wed, 02 Sep 2015 11:01:13 -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> From: Eric Blake Message-ID: <55E70F26.8020506@redhat.com> Date: Wed, 2 Sep 2015 09:00:54 -0600 MIME-Version: 1.0 In-Reply-To: <55E65026.2050902@cn.fujitsu.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LFixEbfQFAct6nvdfE40k68MvhD5KwWAg" 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: Wen Congyang , 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 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LFixEbfQFAct6nvdfE40k68MvhD5KwWAg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 bak= ing >>>> 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 thi= nk >> we are better off using blockdev-add to create a new unattached BDS an= d >> 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. >> >=20 > Good idea. The unattached BDS created by the command blockdev-add alway= s > 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= =2E 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --LFixEbfQFAct6nvdfE40k68MvhD5KwWAg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJV5w8mAAoJEKeha0olJ0NqRjYH/0nNOcAXszZ5XqGWBzyyS/JQ /psrFjNpOaRbsdvUyCnCLEWTYv4NZ6ZZvIZR0A1ZAfuzVC1IdtjUKlCPCzwCnS32 xP79N1uCQltMebIeOMtTr7c16X/VnXdpeKXDPy17Yi4yvS5Oa0P2J+Dcr17932rP 3P3NkfU9dsuDDZJdKm+52WT2tVPo24jEZsttEGJCwJnr3Kl8ZT2rxJquOjRzQolb FA3jfMhj2RnJtS5HhPcSAXZak4xztG92Z5Tfl729QPNTQYceRteiGOakpTFu+Cc9 tzuwcosFCcJ3/pXGVDZ+HQf2NSGdsDMaz7iVqTVZ5PzKwDdfBDZV8dAbIDfkpPo= =DfqH -----END PGP SIGNATURE----- --LFixEbfQFAct6nvdfE40k68MvhD5KwWAg--