On 01/27/2012 10:52 AM, Kevin Wolf wrote:
> Conclusion: eject returned an error, but a few seconds later the tray opened
and
> the media wasn't purged. What happened here is that, the_guest_
> opened the tray. The code in this patch would trigger the
event, but
> we shouldn't emit it twice if we cover eject& change (ie.
special case)
bdrv_dev_change_media_cb is not called because media cannot be ejected
with a locked drive. Instead bdrv_dev_eject_request is called which
doesn't emit an event.
If the guest happens to initiate an eject itself after receiving the
eject request, it calls bdrv_eject, where we can emit an event.
If we had force=true in the initial eject command, bdrv_close is called,
which in turn goes through bdrv_dev_change_media_cb where an event is
emitted.
But we still emit the eject request, and the guest will cause bdrv_eject
to raise the event again.
There can always be a race with the guest setting the locked bit, so
management has to do a query-block anyway after eject or change. That's
why the event is not necessary when the eject is host-initiated.
Paolo
