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

[Kevin Wolf]

Am 25.01.2012 13:42, schrieb Luiz Capitulino:
> On Wed, 25 Jan 2012 09:41:20 +0100
> Kevin Wolf <address@hidden> wrote:
> 
>> Am 24.01.2012 21:03, schrieb Eric Blake:
>>> On 01/24/2012 11:16 AM, Luiz Capitulino wrote:
>>>> Libvirt wants to be notified when the guest ejects a medium, so that
>>>> it can update its view of the guest.
>>>>
>>>> This code has been originally written by Daniel Berrange. It adds
>>>> the event to IDE and SCSI emulation.
>>>>
>>>> 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.

> The exception is if it allows HMP to run in parallel with QMP, but I don't 
> think
> this is recommended (at least not for commands that change any VM state).

Or QMP passthrough.

It would be very nice to support these scenarios one day. Probably not
top priority, but we don't need to actively prevent such events from
being generated.

> That said, I'm not necessarily against covering all cases. It just doesn't
> seem necessary to me.
> 
>> Also, I seem to remember that once we had discussed some kind of a "tray
>> status (open/closed) changed" event, which would be more generic.
> 
> Yes, but my old series got complex and way beyond the original event. If we
> decide to cover all eject scenarios, I'd like to do it w/o adding new 
> commands.

I don't really remember. Were it problems with the design of a tray
status event or were you sidetracked by other problems?

Kevin