Re: [Qemu-devel] [Patch for-2.5 v2 5/6] qmp: add monitor command to add/remove a child

[Wen Congyang <wency@cn.fujitsu.com>]

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