Re: [Xen-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > It might be reasonable for hotplugpath.sh to define
> > XENSTORE_xenstored=/path/to/xenstored
> > XENSTORE_oxenstored=/path/to/oxenstored
> > 
> > and use the existing XENSTORED variable in sysconfig to select which.
> 
> Ah but but hotplugpath.sh is one of those automatically generated files
> and after my last patch in this series they are all now shared in one
> master file, config/xen-environment-scripts.in, and since the we want
> to keep script file Shell / Python agnostic checking which one is set
> on sysconfig is not something reasonable to do on that master file.

Well, it must be possible to change which xenstored implementation is
used by editing a single setting in /etc/{sysconfig,default}/xencommons,
maybe that means more code somewhere, I don't know. idieally you would
be able to say
XENSTORE=xenstored # C xenstore at default path
XENSTORE=oxenstored # Ocaml xenstore at default path
XENSTORE=/path/to/something # xenstored at some custom path.

> My series of patches already deals with the old init and xencommons script to
> start xenstore, it used the hotplugpath.sh for deducing the xenstore
> daemon it should use by default and switching this to rely on the sysconfig
> xencommons should be easy if it wasn't already dealt with there already.
> 
> For systemd though we can't use varibles on ExecStart for the process, we
> however can use environment variables. We have a few options. Fedora's
> approach was to use two service unit files which conflicted with each other,
> although I'm sure we can work it out by using a target unit and let folks
> flip it seems rather silly to me to maintain two service unit files with
> identical entries. Therefore in my new approach usres would have to manually
> edit the service file with the differnt path / binary. Another possibility
> is to have a central launcher binary that just does getenv() and execve()
> on the desired binary. If this is agreeable I can work on it and it could
> even be shared by the old init as well.

Which is considered the most "systemd" approach?

> > >  XEN_PAGING_DIR=/var/lib/xen/xenpaging
> > >  AC_SUBST(XEN_PAGING_DIR)
> > > +
> > > +AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
> > > + AC_PROG_OCAML
> > > + AC_PROG_FINDLIB
> > > + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
> > 
> > THen you could rely on m4/ocaml.m4 to have checked all this already.
> 
> Just including m4/ocaml.m4 won't get us much, the above logic assumes
> that file was included so there is a bit of a trick we need to adjust
> in order to avoid multiple calls to the same checks.

If you do/call these checks in tools/configure.ac then I think you can
just arrange to sequence things correctly with the ocaml ones by the
ordering in the file.

Ian.


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