Avi Kivity <a...@redhat.com> 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.