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

[Avi Kivity]

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.

> > 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.

--
error compiling committee.c: too many arguments to function