On 02/24/2012 10:56 AM, Luiz Capitulino wrote:

On Fri, 24 Feb 2012 10:44:11 -0600 Anthony Liguori<anthony@codemonkey.ws> 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