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

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Feb 14, 2011 at 11:28:52AM -0200, Luiz Capitulino wrote:
> 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?

I've always thought it was bad to have all events enabled all
the time, because it is not scalable as the number & frequency
of events increases. Requiring the app register for each event
it cares about is more scalable & also allows the app to discover
if a particular event is actually supported by that QEMU version.
eg The initial 'qmp_capabilities' greeting from the client could
include the list of all desired event names from the client,
and the server could reply with the list of those event it can
actually support & has enabled.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|