Re: [Qemu-devel] Close the BlockDriverState when guest eject the media

[Markus Armbruster]

Weidong Huang <address@hidden> 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.