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

[Gonglei <arei.gonglei@huawei.com>]

On 2014/10/21 16:33, Markus Armbruster wrote:

> Weidong Huang <hwd@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