[Top][All Lists]
[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
- [Qemu-devel] [PATCH 4/5] qmp: add the GUEST_MEDIUM_EJECTED event, (continued)