[libvirt] [PATCH] add a default event handle, to passthough the new events come from qemu

[shu ming]

On 2011-10-13 17:54, Daniel P. Berrange wrote:
> On Tue, Oct 11, 2011 at 08:46:06AM -0500, Adam Litke wrote:
>> On Mon, Oct 10, 2011 at 11:54:08PM +0800, shaohef at linux.vnet.ibm.com wrote:
>>> From: Shaohe Feng<shaohef at linux.vnet.ibm.com>
>>>
>>> Basically, this feature can go along with qemu monitor passthrough.
>>> That way, if we use new commands in the monitor that generate new events, we want
>>>   some way to receive those new events too.
>> I agree that this patch is very complimentary to the existing tools for qemu
>> interaction (qemu_monitor_command, qemu_attach, etc).  It allows API users to
>> subscribe to events that are not yet handled by libvirt.  I have a couple of
>> design questions about this feature.
>>
>> 1) This feature seems to be a bit qemu specific.  Other qemu-specific APIs
>> (mentioned above) are build into libvirt-qemu.so so that they are kept apart
>> from the hypervisor-neutral parts of the API.  Is it possible to do that for
>> an event handler like this patch implements?  Do we want to enforce such a
>> limit?
> Yep, I agree it ought to be in the QEMU specific library.
>
>> 2) This patch causes a string representing a raw JSON event object to be
>> passed to the callbacks that are registered for the default event.  This seems
>> fine to me.  I do wonder if relying on a 'default' event is a bad thing for an
>> application to do.  Let's say an app decides to handle NEW_EVENT using this
>> default handler.  Then, libvirt gains official support for NEW_EVENT.  When the
>> libvirt package is updated in the application's environment, NEW_EVENT will no
>> longer trigger via the default handler.  Thus, the application is broken by a
>> libvirt upgrade.  Would it be better to have a 'raw event' sink where all events
>> (whether supported or not) would be sent?
> I expect applications will want the event to be dispatched to them,
> regardless of whether libvirt has handled it itself, so that they
> don't have to update themselves to the latest libvirt event API
> immediately.
>
> Also I think it would be better if we were able to connect to explicit JSON
> events, rather than a catch all. THe number of events from QEMU is only
> going to increase over time&  as it does, a 'catch all' becomes increasingly
> bandwidth wasteful.
>
> I'd reckon we want something like this:
>
>
>        typedef void (*virConnectDomainQemuEventCallback)(virConnectPtr conn,
>                                                          virDomainPtr dom,
>                                                          const char *eventName, /* The JSON event name */
>                                                          const char *eventArgs, /* The JSON string of args */
>                                                          void *opaque);
>
>        virConnectDomainQemuEventRegister(virConnectPtr conn,
>                                          virDomainPtr dom, /* option to filter */
>                                          const char *eventName,  /* JSON event name */
>                                          virConnectDomainQemuEventCallback cb,
>                                          void *opaque,
>                                          virFreeCallback freecb);
>        virConnectDomainQemuEventDeregister(virConnectPtr conn,
>                                            int callbackID);
>
>
> in libvirt-qemu.h, and libvirt-qemu.so
If I understand correctly, the idea behind these functions is:  the 
application developers know there is a new QEMU event not known by 
libvirt library yet.
And the developer still requests to add a callback for the new event 
without the upgrade of libvirt .  The functions above provide a QEMU 
specific way to
let the application register the callback by QEMU event without much 
intervention of libvirt.   Then later if we want to promote the QEMU 
specific way to the libvirt,
we should warn the application developer that the QEMU specific way is 
obsolete.

>
> Regards,
> Daniel