[Qemu-devel] New QMP event interface (was Re: [PATCH 5/5] qmp: add DEVICE_TRAY_MOVED event)

[Anthony Liguori]

On 02/24/2012 10:56 AM, Luiz Capitulino wrote:
> On Fri, 24 Feb 2012 10:44:11 -0600
> Anthony Liguori<address@hidden>  wrote:
>
> > > I'm asking because the conversion of events to the qapi is not too far away,
> > > but I think that using QOM will somewhat deprecate the code you have in the
> > > glib branch (besides having to wait for 1.2)?
> >
> > I have some vague ideas about what to do here.  One thought would be to have a
> > standard notifier mechanism in Object that was advertised as a property type.
> > We could then provide an interface via QMP to [un]subscribe to a notifier 
> > property.
>
> This seems to be a good match with your previous ideas, implemented in the glib
> branch. But then subsystems/devices emitting events will have to be converted
> to QOM first...

Well we need to keep the old events for compatibility, so it's really just about 
new events.  I think that by end of 1.2, we would have all non-qdev subsystems 
converted to QOM also so this shouldn't be a problem in practice.

> > I won't get to this until the 1.2 time frame though.  My goals for 1.1 are to
> > get qbus conversions merged and refactor IRQs/MemoryRegions to use QOM.  If time
> > permits, also refactor the PC to better use QOM.
> >
> > If someone wants to tackle events in QOM, I'd be happy to provide some
> > suggestions on where to start.
>
> I'd like to hear about it, but I'm not sure when I'll start working on it.

I've only thought about this roughly, but the problems that need to be solved 
are:

1) Have an object property that corresponds to a NotifierList (easy)

2) Figure out what it means to "get" and "set" a NotifierList.  I think perhaps 
we could somehow turn this into subscribe/unsubscribe...

We could take a plan9-like approach where "get" would return the canonical path 
of a new object that corresponded to a subscription to the event.  This is nice 
because unsubscribing then just becomes a matter of destroying the subscription 
object.

Once you had this subscription object, I think we would want a mechanism to 
"connect" the subscription with either a native function pointer or some 
mechanism that would let us translate that to QMP.  Maybe we only connect with a 
native function pointer and use QAPI generation code to build a native function 
pointer that spits out a marshalled QObject.

3) We would need to think through the QMP interface for all of this.  Given a 
path, we want to be able to subscribe to an event and unsubscribe from an event. 
 We need to unsubscribe all subscribed events when the connection is lost.  It 
would be nice to have convenience interfaces for doing things like subscribing 
to any event on a given type too including yet to be created objects.

Cc'ing libvirt here to see if they have any additional requirements.

Regards,

Anthony Liguori