[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 6/8] block: add eject request callback
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 6/8] block: add eject request callback |
Date: |
Mon, 07 Nov 2011 14:49:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
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