qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_ME


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC 0/5]: QMP: Introduce GUEST_MEDIUM_EJECT & BLOCK_MEDIUM_CHANGED
Date: Fri, 10 Feb 2012 20:39:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0

On 02/10/2012 06:55 PM, Kevin Wolf wrote:
Am 10.02.2012 18:04, schrieb Luiz Capitulino:
This reminds me about an earlier try where I did the following, iirc:

 1. added commands blockdev-tray-open, blockdev-tray-close, 
blockdev-medium-insert,
    blockdev-medium-remove

I think this slightly overengineering. eject and change work well enough, we do not need blockdev-medium-insert and blockdev-medium-remove (yet). Of course there can be a new API, just nothing user-visible.

 2. added the events: BLOCK_TRAY_OPEN, BLOCK_TRAY_CLOSE, BLOCK_MEDIUM_INSERTED
    BLOCK_MEDIUM_REMOVED, which would be emitted when the relating command is 
issued
    (maybe the events could just be BLOCK_TRAY_CHANGED & BLOCK_MEDIUM_CHANGED)

Or even just one event with two boolean arguments.

Looks slightly less clean, but it has an advantage: a guest that sends "eject" can wait for an event and will know whether the eject command was really executed (tray = open, medium = none) or just an eject request was obeyed by the guest (tray = open, medium = present).

Now, maybe the guest eject could also emit BLOCK_TRAY_OPEN & BLOCK_TRAY_CLOSE. 
Then
I think this is a complete solution.

Yes.

Looks good to me in general. I'm not sure how you're imagining to
implement this, I would prefer not to emit events from the device code,
but only from block.c.

... and yes. :)

Another interesting point is what to do with host CD-ROM passthrough. I
think the TRAY_OPEN/CLOSE part is doable (do Paolo's patches actually do
that, so that we just need to add an event?).

It is in the part that I haven't posted yet.

We would have to fake
MEDIUM_REMOVED/INSERTED immediately before a TRAY_CLOSE if the medium
has changed.

Not sure about this, the "medium" hasn't changed in the sense that the backend is still the same.

With passthrough, eject could become a synonym of tray-open. It is very unintuitive that the device is completely disconnected by the backend. And with passthrough, as soon as the guest ejects my CD I know that I have to remove the medium before the guest reboots. In other words we can expect some kind of collaboration from the user.

LOCK/UNLOCK (which you forgot in your list) is only
initiated by the guest or monitor (eject -f), so there's nothing special
with passthrough.

Well, there are a couple of places where we unlock without calling bdrv_lock_medium, those should be fixed so that in the passthrough case we force-unlock the host CD too.

Paolo



reply via email to

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