On Fri, Jan 25, 2013 at 01:20:43PM +0100, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=892289
It seems like with new udev within guest OS, the tray is locked,
so we need to:
- 'eject'
- wait shortly
- 'change'
However, the 'wait shortly' step is better to be substituted with
active polling on tray_open attribute on the device. Moreover,
even when doing bare 'eject', we should check for 'tray_open' as
guest may have locked the tray.
QEMU emits an event when the tray state changes, so we should
just be listening for that. In the case where we have an old
QEMU lacking the tray state event, then we're also missing
the tray state in the block info query, so no worse off. So
just skip the polling and wait for the event to arrive.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|