Re: [Qemu-devel] [PATCH 6/8] block: add eject request callback

[Paolo Bonzini <pbonzini@redhat.com>]

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