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

On Mon, Oct 10, 2011 at 11:54:08PM +0800, shaohef(a)linux.vnet.ibm.com wrote: 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? 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? Tested-by: Adam Litke <agl(a)us.ibm.com&gt; -- Adam Litke <agl(a)us.ibm.com&gt; IBM Linux Technology Center