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? > 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? Thanks.
