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