|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PATCH 6/8] block: add eject request callback |
Date: | Mon, 07 Nov 2011 17:14:30 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 |
On 11/07/2011 04:23 PM, Markus Armbruster wrote:
1. eject without -f is as you mentioned.Would implementing the missing part help with the problem at hand?
It would help for non-buggy guests. Buggy means even "echo -1 > /sys/block/sr0/events_poll_msecs".
However, a full solution would require a change in management, and adding a TRAY_STATUS_CHANGED event to QEMU. Not sure this is required for 1.0, as it can even be added later to stable.
2. eject with -f should really never be needed, but it does whatever is needed to be able to follow up with a "change" command. It turns out it is really "unlock" and "ask the guest to eject" combined, but that's the implementation, not the model.Physical hardware doesn't work that way (unless I misunderstand it). Always a warning sign.
True.
The difference from the paperclip model is that it gives a chance for the OS to clean up and eject safely. It wouldn't be hard to convince me otherwise though, especially if it can help getting the patch in 1.0. The "eject -f"+"change" can be replaced by "eject", possibly followed by "eject -f" after a timeout, and then followed again by "change".On bare metal, the pressing the tray button accomplishes that: the drive notifies the OS the button was pressed, the well-behaved OS cleans up and ejects. With a misbehaving OS, you're reduced to the paperclip. Can't we replicate that? 1. Tray button / eject without -f A. when the tray is not locked: tray opens immediately. B. when the tray is locked: OS gets notified. We expect it to clean up, unlock and open the tray at some point in the near future. 2. Paperclip / eject with -f Tray opens immediately. Guest OS may be unhappy about it.
I now redid my tests with the paperclip behavior (it's really one line of different code) and everything seems to work. Will submit v2.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |