Am 07.01.2013 um 13:36 schrieb Markus Armbruster <arm...@redhat.com>:
> Peter Lieven <p...@dlhnet.de> writes: > >> Hi Paolo, >> >> Am 04.01.2013 um 19:42 schrieb Paolo Bonzini <pbonz...@redhat.com>: >> >>> 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
