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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 14 Feb 2012, Ian Campbell wrote:
> 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.

While I understand that technically is not difficult to achieve and
doesn't add much complexity in terms of lines of code; starting daemons
is cheap and is taken care by xencommons. I am not sure if it is worth
introducing yet another way of doing the same thing.

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