Re: [Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce libxl hotplug public API functions

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-02-14 at 14:23 +0000, Roger Pau Monnà wrote:
> 2012/2/8 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
> > Roger Pau Monne writes ("[Xen-devel] [PATCH 20 of 29 RFC] libxl: introduce 
> > libxl hotplug public API functions"):
> >> libxl: introduce libxl hotplug public API functions
> >>
> >> These functions mimic the name used by the local device functions,
> >> following the nomenclature:
> >
> > I think these should be private functions.  Your new device daemon is,
> > I think, part of the implementation of libxl, not something that
> > another toolstack on top of libxl will reasonably want to replace.
> >
> > This is a new departure for libxl, which doesn't currently have any
> > internal executables.
> 
> Not sure about the best approach here, I though that xldeviced will be
> like xl, but that's something we can discuss about.

I was wondering if perhaps xl/libxl should handle these events by
default (using the same APIs as xldeviced uses) such that in the simple
case users can continue to just use xl without worrying about
configuring or enabling additional daemons. There would then be an
option to disable this if you were running xldeviced (either in dom0 or
in a driver dom). Perhaps a more DWIM extension would be to default to
running things within xl/libxl only if the backend is in dom0 and assu,e
xldeviced is running in backend doms != 0.

Do you integrate with the libxl event loop? If you did wouldn't this be
trivial to handle in xl and wouldn't the xldeviced become the trivial
setup + run the event loop program?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel