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

[Kevin Wolf <kwolf@redhat.com>]

Am 07.11.2011 14:36, schrieb Paolo Bonzini:
> 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.

Does this give different results than just asking the guest to eject
without forcefully unlocking? I would expect that a guest that responds
to the eject request would also unlock the drive. In which case I think
eject without -f should be enough?

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

Kevin