qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]