[Qemu-devel] Re: [RFC] qapi: events in QMP

[Luiz Capitulino <lcapitulino@redhat.com>]

On Sun, 13 Feb 2011 12:08:04 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Hi,
> 
> In my QAPI branch[1], I've now got almost every existing QMP command 
> converted with (hopefully) all of the hard problems solved.  There is 
> only one remaining thing to attack before posting for inclusion and 
> that's events.  Here's my current thinking about what to do.
> 
> Events in QMP Today
> 
> QMP events are asynchronous messages.  They are not tied explicitly to 
> any type of context, do not have a well defined format, and are have no 
> mechanism to mask or filter events.  As of right now, we have somewhere 
> around a dozen events.
> 
> Goals of QAPI
> 
> 1) Make all interfaces consumable in C such that we can use the 
> interfaces in QEMU
> 
> 2) Make all interfaces exposed through a library using code generation 
> from static introspection
> 
> 3) Make all interfaces well specified in a formal schema
> 
> Proposal for events in QAPI
> 
> For QAPI, I'd like to model events on the notion of signals and 
> slots[2].  A client would explicitly connect to a signal through a QMP 
> interface which would result in a slot being added that then generates 
> an event.  Internally in QEMU, we could also connect slots to the same 
> signals.  Since we don't have an object API in QMP, we'd use a pair of 
> connect/disconnect functions that had enough information to identify the 
> signal.

This seems to be the right way to do this in C, but I wonder if it will
get complex/bloated to require this on the wire protocol.

In the initial discussions on QMP events, we decided that it was
simpler/easier to just send all events and let the client do the masking if it
wants to. Later on, Daniel commented that it would be useful to able to mask
events early on.. Now, this proposal will require registration.

We don't seem to make our mind..

Daniel, what do you think?

> Example:
> 
> We would define QEVENT_BLOCK_IO_EVENT as:

I won't comment on the code right now, I want to read it in detail in your
branch, so that I can do a better review. Will try to do it in the next
few days.

My only immediate concern is that, as I commented on the other email, this
new model will require us to add new commands/events when extending existing
commands/events, right?