|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] RFC v2: blockdev_add & friends, brief rationale, QMP docs |
Date: | Tue, 15 Jun 2010 16:40:08 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
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.
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?)
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.
We can't simply keep -drive, because of the flaws I listed in the rationale.
Ok. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |