On 2014/10/21 16:33, Markus Armbruster wrote: > Weidong Huang <h...@huawei.com> writes: > >> On 2014/10/20 20:12, Markus Armbruster wrote: >> >>> >>> Correct. This is a known wart. To work around it, wait for event >>> DEVICE_TRAY_MOVED and eject again. Yes, this is racy: the guest can >>> reclose the tray and lock it before you get your eject in. >> >> >> Yes. You got it. But how to resolve the racy? >> I intend to return fail in this situation. What's your opinion? > > I guess failure is fair then. It's close enough to the case where the > guest simply refuses to open the tray. > >>> Programs really depend on "eject, load, get the same medium back" >>> behavior. Example: https://bugzilla.redhat.com/show_bug.cgi?id=558256 >>> >>> We intend to provide new commands that behave better than "eject". >>> Don't hold your breath. >> >> >> Good news. >> >> I think "eject" command should not to drop the media too. It just only open >> the >> tray, and nothing else. >> >> Calling bdrv_close() could be done in "change media" command. And "change >> media" >> command also can remove the media by null path. >> >> So this problem can be resolved. What do you think of it? > > We want QMP "elementary" commands that do just one thing: eject medium > (open tray), remove medium, insert medium, load mediun (close tray). > > I feel "eject medium (open tray)" should work like pressing the button > on a physical drive: if the tray is unlocked, it opens, else the drive > notifies the OS of the button press. The OS should then unlock and open > when possible. > > Likewise, "remove/insert medium" should work just like they do with a > physical drive: the tray needs to be open already. >
Cool. Follow the physical behavior completely. Best regards, -Gonglei
