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

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

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

I agree we should try to solve the problem for 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.

Would implementing the missing part help with the problem at hand?

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

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