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

[Paolo Bonzini <pbonzini@redhat.com>]

On 11/07/2011 02:21 PM, Markus Armbruster wrote:
> The commit message should explain why we need this callback.  The cover
> letter says "support for eject requests is required by udev 173."
> Please elaborate on that.

Well, first and foremost eject requests are in the spec.  :)  The fact 
that recent guests need it is more a justification for pulling this in 1.0.

> You implement it for IDE in PATCH 7/8 and SCSI in PATCH 8/8.  You don't
> implement it for floppy, despite the comment.  That's okay; floppy has
> no use for it.  It's the comment that needs fixing.  Devices that
> implement is_medium_locked() must implement this one as well.

Right.

> 1. eject without -f behaves like the physical tray button.  It has
> immediate effect, unless the tray is locked closed.  Then, the drive
> just notifies the OS of the button push, so the OS can react to it.  The
> latter isn't implemented in QEMU.
>
> 2. eject with -f behaves like whatever physical way there is to pry the
> tray open, locked or not.  CD-ROM drives commonly have a little button
> hidden in some hope you can reach with a bent paperclip.
>
> Could you explain your mental model?

1. eject without -f is as you mentioned.

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.

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".

Paolo