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.
