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

[Kevin Wolf]

Am 25.01.2012 14:32, schrieb Paolo Bonzini:
> 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.

Good point. The QMP client would still get an error that the device is
locked, and only later receive the event that the guest ejected the
medium, right?

> 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.

In which case we did have an eject request, but we didn't actually
eject. So I think defining it as being emitted whenever something is
ejected/the tray is opened makes sense.

Kevin