Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs

[Markus Armbruster]

Avi Kivity <address@hidden> writes:

> On 06/15/2010 03:23 PM, Markus Armbruster wrote:
>>
>>> media_insert/remove seem to duplicate blockdev_add/del.  Perhaps we
>>> don't need them?
>>>
>>> To change media, tell the guest device to eject, blockdev_del,
>>> blockdev_add, reassociate the guest and host parts.
>>>      
>> Device model code is not prepared to have host parts go away and come
>> back during operation.  The device model driver attaches to the host
>> part on initialization, and detaches only when the device gets destroyed
>> (hot unplug).
>>
>> If we yank out the host part during operation as you propose, then the
>> device model driver's pointer to the host part becomes null.  I don't
>> see that ending happily.
>>    
>
> I'm only talking about the interface, not the implementation.
> Internal design details shouldn't be exposed.
>
> For the implementation, I imagine you can create an empty blockdev
> during guest device creation and treat blockdev_add/blockdev_del as
> media change/eject.

If blockdev_del only ejects media, then we need another command to get
rid of a blockdev.

Unless you propose that blockdev_del merely ejects media if the blockdev
is being used by a device, but destroys the blockdev outright if not.
But that would be sick, wouldn't it?

>>> To pretend you're a media changer, blockdev_add all your cds at once
>>> and just change the guest/host association when you want to hear a new
>>> band.
>>>
>>> For a fake a multipath setup, blockdev_add one device, associate it
>>> with multiple guest interfaces.
>>>
>>> Otherwise, looks good.
>>>      
>> Any preference on the command line option syntax?
>>    
>
> Something incredibly long and complicated?
>
> We might keep the existing stuff which is already complicated enough
> for users, and ask machines to build guests using QMP instead of the
> command line.

I sketched three ways to do -blockdev.  They attempt to make the simple
simple, and the complex possible.  Any preference among them?

We can't simply keep -drive, because of the flaws I listed in the
rationale.