[Libvir] Re: Asynchronous notifications of domain start/stop

[Daniel P. Berrange]

On Wed, Jul 18, 2007 at 10:46:02AM -0400, Daniel Veillard wrote:
> 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.

Because this assumes that a single FD is all you'll ever need to monitor
which isn't neccessarily the case with all drivers. The add/remove handle
funcs let the driver provide the application with FD as & when they are
needed. From what I understand of XenAPI, the way they provide state 
notifications requires multiple FDs, and we shouldn't artifically limit
ourselves since there's many other virt systems we still may support in
the future which may have have a single pre-determined 'fd'.

The callbacks really aren't that hard to understand and we already have this 
stuff in the internal API since we need it for QEMU driver, so we wouldn't
be adding any new code to libvirt in that regard - merely reusing existing 
infrastructure.

> 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).

Not exactly a great comparison, as SAX / XML Readers aren't trying to 
monitor an arbitrary external dynamically changing state system.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|