Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event

[Markus Armbruster]

Paolo Bonzini <address@hidden> 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.