Avi Kivity <a...@redhat.com> writes: > On 06/15/2010 04:27 PM, Markus Armbruster wrote: >> >>> 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. >> > > No. If you have a blockdev just to satisfy the guest device's need > for a blockdev pointer, you can delete it automatically when the last > reference goes.
That's not how netdev and chardev behave. >> 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? >> > > Create a blockdev implicitly with guest device creation, and use > blockdev_add (or media_attach) to attach the media. > > (but that creates a window where the guest device is visible but media > is not yet inserted?) Think so, for hot plug. Actually, the device model driver would reject an empty blockdev, unless it's a device with removable media, such as a CD-ROM. Having a device with fixed media go through a "no media yet" state during initialization just complicates things. Defining the media *before* creating the device is much simpler. >>>>> 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? >> >> > > I'll look again. Thanks! >> We can't simply keep -drive, because of the flaws I listed in the >> rationale. >> > > Ok.