Re: [Qemu-devel] QEMU CDROM tray-open and locked logic

[Peter Lieven]

Am 07.01.2013 um 13:36 schrieb Markus Armbruster <address@hidden>:

> Peter Lieven <address@hidden> writes:
> 
>> Hi Paolo,
>> 
>> Am 04.01.2013 um 19:42 schrieb Paolo Bonzini <address@hidden>:
>> 
>>> Il 04/01/2013 11:26, Peter Lieven ha scritto:
>>>> Hi,
>>>> 
>>>> i have observed the following with qemu-kvm-1.2.0 which I think is not 
>>>> right:
>>>> 
>>>> a) if the CDROM is locked and I sent a eject command I get the error that 
>>>> the
>>>> CDROM is locked, but its ejected nevertheless.
>>> 
>>> That's because the CD-ROM sends an "eject requested" event, and udev
>>> does the unlock & eject itself.
>> 
>> ah ok, this explains it.
>> 
>>> 
>>>> b) if I eject the CDROM in the OS I see tray-open=1 and locked=1. In the
>>>> tray-open=1 state the CDROM can`t be locked, can it?
>>> 
>>> A "real" CD-ROM drive could have the tray open and not responding to the
>>> button.  Table 330 of MMC6 matches "Operation Lock, current prevent
>>> state Locked, No media present" to "No Error, media insertion is not
>>> permitted".  I cannot check right now what happens later and whether
>>> QEMU's behavior makes sense.
>> 
>> okay, so this could be also correct.
> 
> For what it's worth, my physical CD-ROM can be locked while the tray is
> open.  It stays locked when the tray closes.
> 
>> last question. if the OS opens the tray, the cdrom is still inserted in the
>> case that the iso is still inserted. this behavior is also ok, but its a 
>> little
>> confusing. this leads to a lot of cases that have to be checked regarding
>> cdroms in qemu.
> 
> I'm not sure I got your question, but perhaps the following helps
> anyway.
> 
> OS opening the tray affects just the tray.  It doesn't remove media from
> the tray.  This is important, because programs exist that open the tray,
> close the tray, and expect to get their medium back unless the user
> actively changed it.  See commit 4be9762a and
> https://bugzilla.redhat.com/show_bug.cgi?id=558256#c7.

I can't access the bug, but it seems to explain what I observed.

Thanks for the info!

Peter