On 02/24/2012 10:56 AM, Luiz Capitulino wrote:
On Fri, 24 Feb 2012 10:44:11 -0600
Anthony Liguori<anth...@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
