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

[Paolo Bonzini]

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