Paolo Bonzini <pbonz...@redhat.com> writes: > On 01/25/2012 02:23 PM, Kevin Wolf wrote: >> > > > Please, note that this only covers guest initiated ejects, that's, >> > > > the QMP/HMP commands 'eject' and 'change' are not covered. >> > > >> > > What's the reason for this behaviour? It feels inconsistent. >> > >> > I don't think it's inconsistent because we're limiting it to guest >> > initiated >> > actions. Also, the mngt app knows when it sends a 'eject' or 'change' >> > command. >> >> Yes, management shouldn't need an event in order to see what it just did >> itself. I haven't really looked at the code yet, but what I want to >> avoid is that we have to pass a flag all the way through qemu just so we >> don't send an event in the end. This might not be the case today, but >> after some more cleanup of the code it might just turn out like this. > > Management must be ready anyway to receive an event in response to > eject/change actions that it started, because the guest might be > trapping the host's eject requests ("press the button") and turning > them into guest-initiated ejects. This is what recent udev does. > > Thus, a reliable eject procedure must be as follows: > > 1) Eject the disc > > 2) query the state of the tray. If it is open, poll for eject events > and consume them. If it is closed, either exit or wait for an eject > event to arrive. > > We can document that the event MAY NOT be reported for host-initiated > ejects. It is future-proof and actually closer to what happens in > practice if you consider a wide range of guests.
This is getting complicated... Feels like reporting tray open/close changes regardless of who triggered them could be simpler.