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, shao...@linux.vnet.ibm.com wrote:
From: Shaohe Feng<shao...@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
