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

[Anthony Liguori]

On 02/14/2011 07:28 AM, Luiz Capitulino wrote:
> On Sun, 13 Feb 2011 12:08:04 -0600
> Anthony Liguori<address@hidden>  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.
>    

It adds a bunch of new RPC functions, but I don't see a better way.

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

No, optional parameters are supported.  This changes the structure size 
and function signature which means that libqmp has to bump it's version 
number but from a wire protocol perspective, a new and/or libqmp will 
work just fine with all versions of QEMU that support QMP.

The version bump of libqmp is surely undesirable though so we should 
restrict these type of changes.  It's very hard to make this type of 
change in a compatible way regardless of C though so that's generally true.

Regards,

Anthony Liguori