Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-01-07 at 12:21 +0100, Juergen Gross wrote:
> On 07/01/16 11:55, Ian Campbell wrote:
> > On Thu, 2016-01-07 at 11:44 +0100, Juergen Gross wrote:
> > > > > IMO the generic concept you are asking for should be added in a
> > > > > separate patch handling stopping (and possibly rebooting) driver
> > > > > domains in a clean way.
> > > > 
> > > > Since libxl has a stable API once we add something we need to
> > > > continue
> > > > supporting it, so we cannot (easily/cleanly) switch an xs specific
> > > > scheme
> > > > into a generic one later. That argues then for supporting the XS
> > > > case
> > > > via
> > > > the generic mechanism now, even if we don't implement the other
> > > > cases.
> > > 
> > > I can't see a scenario where the xenstore domain would have to be
> > > stopped by dom0. Once you do it you'll never be able to connect to
> > > it again without changing the xenbus driver interface, too. It is
> > > the same reason why xenstored can't be restarted.
> > > 
> > > Driver domains are different and I think the interface to query a
> > > domain whether it is a driver domain or whether it might survive a
> > > dom0 reboot should be based on xenstore.
> > > 
> > > So a xenstore domain would always need special handling.
> > 
> > If there is really _never_ any reason to stop the xs domain then I
> > think at
> > the libxl API level a class of "never stop" domains would be better
> > than
> > special casing the xs, even if it turns out the only member of the set
> > is
> > xs at least we've given ourselves wriggle room if something else comes
> > up
> > in the future.
> 
> Okay, so this would translate to either:
> 
> - add a "never stop" flag to libxl_dominfo (can I do this without
> Â breaking the API?)
> - add a new call interface to either check a single domain to be of
> Â the "never stop" class or to return a list of those domains.
> 
> Preferences?

Definitely the former, with a LIBXL_HAVE_ #define in libxl.h so consumers
know they can use it.

Wei, Ian, do you agree with this approach?

Ian.

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