Paolo Bonzini <pbonz...@redhat.com> 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.