On Wed, Jul 18, 2007 at 03:18:03PM +0100, Daniel P. Berrange wrote:
On Wed, Jul 18, 2007 at 12:57:37PM +0100, Richard W.M. Jones wrote:
> In the qemu case I'm not sure how to modify qemu_driver.c to handle
> this. One for Dan Berrange to comment on.
We should not explicitly expose 'the xenstore filehandle', or 'the
libvirtd'
filehandle per-se. Instead we should provide an API which lets application
register callbacks for adding/removing file handles to an event loop.
We in fact already have this - look at the src/event.h file. So if we make
this part of the official public API, then applications merely need provide
an impl of the virEventAddHandleFunc and virEventRemoveHandleFunc. The
underlying libvirt drivers can thus invoke these callbacks as required,
be it with the XenStored filehandle, a XenAPI filehandle, a libvirtd fd
or something else.
We can provide sample impls of the virEventAddHandleFunc and
virEventRemoveHandleFunc code for GLib and/or QT in a libvirtglib.so
and libvirtqt.so add-on libraries. This allows for easy integration
with most GUI apps, while also allowing integration with custom home
brew event loops. This is how DBus provides event loop integration
without tieing itself to a specific impl & it works very nicely.
Hum, on one hand you have a simple "here is an fd, register it and
call this when there is something to read" and on the other hand there
is an indirect callback architecture, with possibly multiple shared libs.
Isn't this a bit over the top ? Plus I really prefer to have an API
not based on callbacks but on synchronous calls driven by the application.
My own experience is that it is way more comfortable with the later
at least for most programmers (e.g. SAX vs. Reader XML APIs).
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/