[PATCH v8 0/6] xen: systemd support

[PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Here's my v8 series. Quite a bit of patches are alreayd merged
on the xen origin/staging branch, this addresses the last feedback
from the v7 series and is rebased. It contains two fixes spotted
as possible issues by Ian Campbell.

I think this is it, after about 2 months of spinning patches. Phew.

Luis R. Rodriguez (6):
  cxenstored: also fail if only 1 socket was given by systemd
  oxenstored: also fail if only 1 socket was given by systemd
  autoconf: xen: move standard path variables to config/Paths.mk.in
  xencommons: move module list into a generic place
  autoconf: xen: enable explicit preference option for xenstored
    preference
  systemd: add xen systemd service and module files

 .gitignore                                         |   6 +
 Makefile                                           |   6 +-
 README                                             |  60 ++++++++++
 config/Linux.modules                               |  20 ++++
 config/Paths.mk.in                                 |  37 +++++++
 config/Stubdom.mk.in                               |   1 +
 config/Tools.mk.in                                 |   6 +
 configure.ac                                       |   8 +-
 m4/README.source                                   |   8 ++
 m4/paths.m4                                        |  61 ++++++++++
 m4/systemd.m4                                      | 123 +++++++++++++++++++++
 m4/xenstored.m4                                    |  56 ++++++++++
 tools/Rules.mk                                     |   1 +
 tools/configure.ac                                 |  30 ++++-
 tools/hotplug/Linux/Makefile                       |  17 ++-
 ...ysconfig.xencommons => sysconfig.xencommons.in} |  13 ++-
 .../Linux/init.d/{xencommons => xencommons.in.in}  |  24 +---
 tools/hotplug/Linux/systemd/Makefile               |  67 +++++++++++
 tools/hotplug/Linux/systemd/proc-xen.mount.in      |   9 ++
 .../Linux/systemd/var-lib-xenstored.mount.in       |  13 +++
 .../systemd/xen-qemu-dom0-disk-backend.service.in  |  22 ++++
 .../hotplug/Linux/systemd/xen-watchdog.service.in  |  13 +++
 tools/hotplug/Linux/systemd/xenconsoled.service.in |  20 ++++
 tools/hotplug/Linux/systemd/xendomains.service.in  |  16 +++
 tools/hotplug/Linux/systemd/xenstored.service.in   |  27 +++++
 tools/hotplug/Linux/systemd/xenstored.socket.in    |  11 ++
 tools/hotplug/Linux/systemd/xenstored_ro.socket.in |  11 ++
 tools/hotplug/Linux/update-modules.sh              |  30 +++++
 tools/ocaml/xenstored/Makefile                     |   5 +
 tools/ocaml/xenstored/systemd_stubs.c              |   2 +-
 tools/xenstore/Makefile                            |   6 +
 tools/xenstore/xenstored_core.c                    |   2 +-
 32 files changed, 695 insertions(+), 36 deletions(-)
 create mode 100644 config/Linux.modules
 create mode 100644 config/Paths.mk.in
 create mode 100644 m4/paths.m4
 create mode 100644 m4/systemd.m4
 create mode 100644 m4/xenstored.m4
 rename tools/hotplug/Linux/init.d/{sysconfig.xencommons => sysconfig.xencommons.in} (63%)
 rename tools/hotplug/Linux/init.d/{xencommons => xencommons.in.in} (82%)
 create mode 100644 tools/hotplug/Linux/systemd/Makefile
 create mode 100644 tools/hotplug/Linux/systemd/proc-xen.mount.in
 create mode 100644 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
 create mode 100644 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xen-watchdog.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xenconsoled.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xendomains.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xenstored.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in
 create mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in
 create mode 100755 tools/hotplug/Linux/update-modules.sh

-- 
2.0.1

[PATCH v8 1/6] cxenstored: also fail if only 1 socket was given by systemd

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Reported-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 tools/xenstore/xenstored_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 7f72f68..4eaff57 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1770,7 +1770,7 @@ static void xen_claim_active_sockets(int **psock, int **pro_sock)
 			   strerror(errno),
 			   errno);
 		barf_perror("sd_listen_fds() failed\n");
-	} else if (n > 2) {
+	} else if (n != 2) {
 		fprintf(stderr, SD_ERR "Expected 2 fds but given %d\n", n);
 		sd_notifyf(0, "STATUS=Mismatch on number (2): %s\n"
 			   "ERRNO=%d",
-- 
2.0.1

[PATCH v8 2/6] oxenstored: also fail if only 1 socket was given by systemd

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Reported-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 tools/ocaml/xenstored/systemd_stubs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/ocaml/xenstored/systemd_stubs.c b/tools/ocaml/xenstored/systemd_stubs.c
index a368ac1..623592c 100644
--- a/tools/ocaml/xenstored/systemd_stubs.c
+++ b/tools/ocaml/xenstored/systemd_stubs.c
@@ -72,7 +72,7 @@ CAMLprim value ocaml_sd_listen_fds(value connect_to)
 			   strerror(errno),
 			   errno);
 		caml_failwith("ocaml_sd_listen_fds() failed to get any sockets");
-	} else if (n > 2) {
+	} else if (n != 2) {
 		fprintf(stderr, SD_ERR "Expected 2 fds but given %d\n", n);
 		sd_notifyf(0, "STATUS=Mismatch on number (2): %s\n"
 			   "ERRNO=%d",
-- 
2.0.1

[PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This moves all generic path variables to a new the config/Paths.mk.in
input source file to be processed at configure time, tons of files use
these so this just share them. This also paves the way to let us
easily dynamically configure these with autoconf, for now we leave the
same presets as was present before.

This work was prompted by looking for an autoconf way to do
replacements for the hotplug global file, while at it I realized
that a few other files use the same variables and have in places
around the tree the same constructs for generating their own
files. This makes use of the old buildmakevars2file() but generalizes
the definition of the paths at configure time and spreads the
new definitions out throughout the build system.

This has no impact on building the hypervisor and extras/mini-os,
you do not need to, and are not expected to, run configure to build
those targets.

While at it lets add some documentation on the for the two files on
the source file, we can expand further details on the wiki [0].

[0] http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration

Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 .gitignore           |  1 +
 config/Paths.mk.in   | 37 +++++++++++++++++++++++++++++++
 config/Stubdom.mk.in |  1 +
 configure.ac         |  8 ++++++-
 m4/paths.m4          | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 tools/Rules.mk       |  1 +
 6 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 config/Paths.mk.in
 create mode 100644 m4/paths.m4

diff --git a/.gitignore b/.gitignore
index fefe13c..f1d1b9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,7 @@ config.log
 config.status
 config.cache
 config/Toplevel.mk
+config/Paths.mk
 
 build-*
 dist/*
diff --git a/config/Paths.mk.in b/config/Paths.mk.in
new file mode 100644
index 0000000..507b6d1
--- /dev/null
+++ b/config/Paths.mk.in
@@ -0,0 +1,37 @@
+# Xen system configuration
+# ========================
+#
+# Xen uses a set of variables for system configuration and at build time,
+# because of this these variables are defined on one master input source file
+# and is generated after running ./configure. The master source is located
+# on the xen source tree at under config/Paths.mk.in and it is used to
+# generate shell or header files by the build system upon demand through the
+# use of the helper makefile helper buildmakevars2file().
+#
+# For more documentation you can refer to the wiki:
+#
+# http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
+
+SBINDIR                  := @SBINDIR@
+BINDIR                   := @BINDIR@
+LIBEXEC                  := @LIBEXEC@
+
+SHAREDIR                 := @SHAREDIR@
+LIBDIR                   := @LIBDIR@
+
+XEN_RUN_DIR              := @XEN_RUN_DIR@
+XEN_LOG_DIR              := @XEN_LOG_DIR@
+XEN_LIB_STORED           := @XEN_LIB_STORED@
+
+CONFIG_DIR               := @CONFIG_DIR@
+XEN_LOCK_DIR             := @XEN_LOCK_DIR@
+XEN_PAGING_DIR           := @XEN_PAGING_DIR@
+
+PRIVATE_PREFIX           := @PRIVATE_PREFIX@
+PRIVATE_PREFIX           := @PKG_XEN_PREFIX@
+PRIVATE_BINDIR           := @PRIVATE_BINDIR@
+
+XENFIRMWAREDIR           := @XENFIRMWAREDIR@
+
+XEN_CONFIG_DIR           := @XEN_CONFIG_DIR@
+XEN_SCRIPT_DIR           := @XEN_SCRIPT_DIR@
diff --git a/config/Stubdom.mk.in b/config/Stubdom.mk.in
index 302842e..6bce206 100644
--- a/config/Stubdom.mk.in
+++ b/config/Stubdom.mk.in
@@ -1,4 +1,5 @@
 # Prefix and install folder
+include $(XEN_ROOT)/config/Paths.mk
 prefix              := @prefix@
 PREFIX              := $(prefix)
 exec_prefix         := @exec_prefix@
diff --git a/configure.ac b/configure.ac
index 6c14524..f32f9af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,12 +5,18 @@ AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor], m4_esyscmd([./version.sh ./xen/Makefile]),
     [xen-devel@lists.xen.org], [xen], [http://www.xen.org/])
 AC_CONFIG_SRCDIR([./xen/common/kernel.c])
-AC_CONFIG_FILES([./config/Toplevel.mk])
+AC_CONFIG_FILES([
+	config/Toplevel.mk
+	config/Paths.mk
+])
 
 AC_CANONICAL_HOST
 
 m4_include([m4/features.m4])
 m4_include([m4/subsystem.m4])
+m4_include([m4/paths.m4])
+
+AX_XEN_EXPAND_CONFIG()
 
 dnl mini-os is only ported to certain platforms
 case "$host_cpu" in
diff --git a/m4/paths.m4 b/m4/paths.m4
new file mode 100644
index 0000000..717fcd1
--- /dev/null
+++ b/m4/paths.m4
@@ -0,0 +1,61 @@
+AC_DEFUN([AX_XEN_EXPAND_CONFIG], [
+dnl expand these early so we can use this for substitutions
+test "x$prefix" = "xNONE" && prefix=$ac_default_prefix
+test "x$exec_prefix" = "xNONE" && exec_prefix=$ac_default_prefix
+
+BINDIR=$prefix/bin
+AC_SUBST(BINDIR)
+
+SBINDIR=$prefix/sbin
+AC_SUBST(SBINDIR)
+
+dnl XXX: this should be changed to use the passed $libexec
+dnl but can be done as a second step
+LIBEXEC=$prefix/lib/xen/bin
+AC_SUBST(LIBEXEC)
+
+LIBDIR=`eval echo $libdir`
+AC_SUBST(LIBDIR)
+
+XEN_RUN_DIR=/var/run/xen
+AC_SUBST(XEN_RUN_DIR)
+
+XEN_LOG_DIR=/var/log/xen
+AC_SUBST(XEN_LOG_DIR)
+
+XEN_LIB_STORED=/var/lib/xenstored
+AC_SUBST(XEN_LIB_STORED)
+
+SHAREDIR=$prefix/share
+AC_SUBST(SHAREDIR)
+
+PRIVATE_PREFIX=$LIBDIR/xen
+AC_SUBST(PRIVATE_PREFIX)
+
+PKG_XEN_PREFIX=$LIBDIR/xen
+AC_SUBST(PKG_XEN_PREFIX)
+
+PRIVATE_BINDIR=$PRIVATE_PREFIX/bin
+AC_SUBST(PRIVATE_BINDIR)
+
+XENFIRMWAREDIR=$prefix/lib/xen/boot
+AC_SUBST(XENFIRMWAREDIR)
+
+CONFIG_DIR=/etc
+AC_SUBST(CONFIG_DIR)
+
+XEN_CONFIG_DIR=$CONFIG_DIR/xen
+AC_SUBST(XEN_CONFIG_DIR)
+
+XEN_SCRIPT_DIR=$XEN_CONFIG_DIR/scripts
+AC_SUBST(XEN_SCRIPT_DIR)
+
+XEN_LOCK_DIR=/var/lock
+AC_SUBST(XEN_LOCK_DIR)
+
+XEN_RUN_DIR=/var/run/xen
+AC_SUBST(XEN_RUN_DIR)
+
+XEN_PAGING_DIR=/var/lib/xen/xenpaging
+AC_SUBST(XEN_PAGING_DIR)
+])
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 9ac8541..0aa1e6b 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -5,6 +5,7 @@ all:
 
 -include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/Config.mk
+include $(XEN_ROOT)/config/Paths.mk
 
 export _INSTALL := $(INSTALL)
 INSTALL = $(XEN_ROOT)/tools/cross-install
-- 
2.0.1

Re: [PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Julien Grall]

Hi,

On 07/26/2014 03:14 AM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This moves all generic path variables to a new the config/Paths.mk.in
> input source file to be processed at configure time, tons of files use
> these so this just share them. This also paves the way to let us
> easily dynamically configure these with autoconf, for now we leave the
> same presets as was present before.
> 
> This work was prompted by looking for an autoconf way to do
> replacements for the hotplug global file, while at it I realized
> that a few other files use the same variables and have in places
> around the tree the same constructs for generating their own
> files. This makes use of the old buildmakevars2file() but generalizes
> the definition of the paths at configure time and spreads the
> new definitions out throughout the build system.
> 
> This has no impact on building the hypervisor and extras/mini-os,
> you do not need to, and are not expected to, run configure to build
> those targets.
> 
> While at it lets add some documentation on the for the two files on
> the source file, we can expand further details on the wiki [0].
> 
> [0] http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration

With this patch applied on xen tree (see commit 54f2891), the libraries will always be
copied in /usr/local/lib even if --prefix=/usr is specified to the configure.

It's a bit annoying as I used this options daily to build Xen and we have test suite relying
on this option.

Here my config/Paths.mk generated:

# Xen system configuration
# ========================
#
# Xen uses a set of variables for system configuration and at build time,
# because of this these variables are defined on one master input source file
# and is generated after running ./configure. The master source is located
# on the xen source tree at under config/Paths.mk.in and it is used to
# generate shell or header files by the build system upon demand through the
# use of the helper makefile helper buildmakevars2file().
#
# For more documentation you can refer to the wiki:
#
# http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration

SBINDIR                  := /usr/sbin
BINDIR                   := /usr/bin
LIBEXEC                  := /usr/lib/xen/bin

SHAREDIR                 := /usr/share
LIBDIR                   := /usr/local/lib

XEN_RUN_DIR              := /var/run/xen
XEN_LOG_DIR              := /var/log/xen
XEN_LIB_STORED           := /var/lib/xenstored

CONFIG_DIR               := /etc
XEN_LOCK_DIR             := /var/lock
XEN_PAGING_DIR           := /var/lib/xen/xenpaging

PRIVATE_PREFIX           := /usr/local/lib/xen
PRIVATE_PREFIX           := /usr/local/lib/xen
PRIVATE_BINDIR           := /usr/local/lib/xen/bin

XENFIRMWAREDIR           := /usr/lib/xen/boot

XEN_CONFIG_DIR           := /etc/xen
XEN_SCRIPT_DIR           := /etc/xen/scripts

Regards,

-- 
Julien Grall

Re: [PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Ian Campbell]

On Mon, 2014-08-04 at 15:24 +0100, Julien Grall wrote:
> Hi,
> 
> On 07/26/2014 03:14 AM, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > This moves all generic path variables to a new the config/Paths.mk.in
> > input source file to be processed at configure time, tons of files use
> > these so this just share them. This also paves the way to let us
> > easily dynamically configure these with autoconf, for now we leave the
> > same presets as was present before.
> > 
> > This work was prompted by looking for an autoconf way to do
> > replacements for the hotplug global file, while at it I realized
> > that a few other files use the same variables and have in places
> > around the tree the same constructs for generating their own
> > files. This makes use of the old buildmakevars2file() but generalizes
> > the definition of the paths at configure time and spreads the
> > new definitions out throughout the build system.
> > 
> > This has no impact on building the hypervisor and extras/mini-os,
> > you do not need to, and are not expected to, run configure to build
> > those targets.
> > 
> > While at it lets add some documentation on the for the two files on
> > the source file, we can expand further details on the wiki [0].
> > 
> > [0] http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
> 
> With this patch applied on xen tree (see commit 54f2891), the libraries will always be
> copied in /usr/local/lib even if --prefix=/usr is specified to the configure.

I posted a fix in
http://lists.xen.org/archives/html/xen-devel/2014-08/msg00322.html

I also noticed another issue with this patch, I'll reply about this in a
moment.

Ian

Re: [PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Ian Campbell]

On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:

> +PRIVATE_PREFIX           := @PRIVATE_PREFIX@
> +PRIVATE_PREFIX           := @PKG_XEN_PREFIX@

This is here twice. Is one of these lines wrong or redundant? Please
post an update ASAP.

PKG_XEN_PREFIX seems to be something which is only used here and in
m4/paths.m4. Perhaps it should be removed?

Ian.

Re: [PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Luis R. Rodriguez]

On Mon, Aug 04, 2014 at 03:30:08PM +0100, Ian Campbell wrote:
> On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> 
> > +PRIVATE_PREFIX           := @PRIVATE_PREFIX@
> > +PRIVATE_PREFIX           := @PKG_XEN_PREFIX@
> 
> This is here twice. Is one of these lines wrong or redundant? Please
> post an update ASAP.

Sorry for the delay, will post fix now.

> PKG_XEN_PREFIX seems to be something which is only used here and in
> m4/paths.m4. Perhaps it should be removed?

Indeed. That's what we'll do.

  Luis

Re: [PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Olaf Hering]

On Tue, Sep 23, Luis R. Rodriguez wrote:

> On Mon, Aug 04, 2014 at 03:30:08PM +0100, Ian Campbell wrote:
> > On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > 
> > > +PRIVATE_PREFIX           := @PRIVATE_PREFIX@
> > > +PRIVATE_PREFIX           := @PKG_XEN_PREFIX@
> > 
> > This is here twice. Is one of these lines wrong or redundant? Please
> > post an update ASAP.
> 
> Sorry for the delay, will post fix now.

My --prefix series sent out yesterday covers that already.

Olaf

Re: [PATCH v8 3/6] autoconf: xen: move standard path variables to config/Paths.mk.in

[Luis R. Rodriguez]

On Tue, Sep 23, 2014 at 10:15 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Sep 23, Luis R. Rodriguez wrote:
>
>> On Mon, Aug 04, 2014 at 03:30:08PM +0100, Ian Campbell wrote:
>> > On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
>> >
>> > > +PRIVATE_PREFIX           := @PRIVATE_PREFIX@
>> > > +PRIVATE_PREFIX           := @PKG_XEN_PREFIX@
>> >
>> > This is here twice. Is one of these lines wrong or redundant? Please
>> > post an update ASAP.
>>
>> Sorry for the delay, will post fix now.
>
> My --prefix series sent out yesterday covers that already.

OK thanks, will move on with life.

 Luis

[PATCH v8 4/6] xencommons: move module list into a generic place

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This will allow us to share the same module list with
systemd, and lets us upkeep it in one place. Document this
while at it on the top level README and expand on the wiki:

http://wiki.xen.org/wiki/Category:Host_Configuration#Kernel_modules

In order to upkeep parallelism builds be explicit about the
requirement to complete all actions before any installation
targets.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 README                                             | 12 +++++++++
 config/Linux.modules                               | 20 +++++++++++++++
 tools/hotplug/Linux/Makefile                       | 11 +++++---
 .../Linux/init.d/{xencommons => xencommons.in}     | 16 +-----------
 tools/hotplug/Linux/update-modules.sh              | 30 ++++++++++++++++++++++
 5 files changed, 70 insertions(+), 19 deletions(-)
 create mode 100644 config/Linux.modules
 rename tools/hotplug/Linux/init.d/{xencommons => xencommons.in} (89%)
 create mode 100755 tools/hotplug/Linux/update-modules.sh

diff --git a/README b/README
index 9bbe734..0c8c7aa 100644
--- a/README
+++ b/README
@@ -183,3 +183,15 @@ There are optional targets as part of Xen's top-level makefile that will
 download and build tboot: install-tboot, build-tboot, dist-tboot, clean-tboot.
 These will download the latest tar file from the SourceForge site using wget,
 then build/install/dist according to Xen's settings.
+
+Required Kernel modules
+======================
+
+Xen has a set of Kernel modules which the init scripts ensure to load before
+before starting Xen guests. The list of modules are maintained in one place:
+
+  * config/$(XEN_OS).modules
+
+For more details refer to:
+
+http://wiki.xen.org/wiki/Category:Host_Configuration#Kernel_modules
diff --git a/config/Linux.modules b/config/Linux.modules
new file mode 100644
index 0000000..8a764df
--- /dev/null
+++ b/config/Linux.modules
@@ -0,0 +1,20 @@
+# The file supports a simple language, comments are ignored, and if you there
+# are module replacements this can be listed by using a pipe to show preference
+# for the first module, followed by the older module.
+
+xen-evtchn
+xen-gntdev
+xen-gntalloc
+xen-blkback
+xen-netback
+xen-pciback
+evtchn
+gntdev
+netbk
+blkbk
+xen-scsibk
+usbbk
+pciback
+xen-acpi-processor
+# Prefer to load blktap2 if found, otherwise load blktap
+blktap2|blktap
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index d5de9e6..f85e8ab 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -33,17 +33,20 @@ UDEV_RULES_DIR = $(CONFIG_DIR)/udev
 UDEV_RULES = xen-backend.rules $(UDEV_RULES-y)
 
 .PHONY: all
-all:
+all: $(XENCOMMONS_INITD)
+
+$(XENCOMMONS_INITD): $(XEN_ROOT)/config/$(XEN_OS).modules $(XENCOMMONS_INITD).in
+	$(XEN_ROOT)/tools/hotplug/Linux/update-modules.sh > $@
 
 .PHONY: build
-build:
+build: all
 
 .PHONY: install
 install: all install-initd install-scripts install-udev
 
 # See docs/misc/distro_mapping.txt for INITD_DIR location
 .PHONY: install-initd
-install-initd:
+install-initd: all
 	[ -d $(DESTDIR)$(INITD_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(INITD_DIR)
 	[ -d $(DESTDIR)$(SYSCONFIG_DIR) ] || $(INSTALL_DIR) $(DESTDIR)$(SYSCONFIG_DIR)
 	[ -d $(DESTDIR)$(LIBEXEC) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC)
@@ -55,7 +58,7 @@ install-initd:
 	$(INSTALL_PROG) init.d/xen-watchdog $(DESTDIR)$(INITD_DIR)
 
 .PHONY: install-scripts
-install-scripts:
+install-scripts: all
 	[ -d $(DESTDIR)$(XEN_SCRIPT_DIR) ] || \
 		$(INSTALL_DIR) $(DESTDIR)$(XEN_SCRIPT_DIR)
 	set -e; for i in $(XEN_SCRIPTS); \
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons.in
similarity index 89%
rename from tools/hotplug/Linux/init.d/xencommons
rename to tools/hotplug/Linux/init.d/xencommons.in
index 4ebd636..3939bcc 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -57,21 +57,7 @@ do_start () {
         local time=0
 	local timeout=30
 
-	modprobe xen-evtchn 2>/dev/null
-	modprobe xen-gntdev 2>/dev/null
-	modprobe xen-gntalloc 2>/dev/null
-	modprobe xen-blkback 2>/dev/null
-	modprobe xen-netback 2>/dev/null
-	modprobe xen-pciback 2>/dev/null
-	modprobe evtchn 2>/dev/null
-	modprobe gntdev 2>/dev/null
-	modprobe netbk 2>/dev/null
-	modprobe blkbk 2>/dev/null
-	modprobe xen-scsibk 2>/dev/null
-	modprobe usbbk 2>/dev/null
-	modprobe pciback 2>/dev/null
-	modprobe xen-acpi-processor 2>/dev/null
-	modprobe blktap2 2>/dev/null || modprobe blktap 2>/dev/null
+	@LOAD_MODULES@
 	mkdir -p /var/run/xen
 
 	if ! `${BINDIR}/xenstore-read -s / >/dev/null 2>&1`
diff --git a/tools/hotplug/Linux/update-modules.sh b/tools/hotplug/Linux/update-modules.sh
new file mode 100755
index 0000000..f9c10e2
--- /dev/null
+++ b/tools/hotplug/Linux/update-modules.sh
@@ -0,0 +1,30 @@
+#!/bin/bash
+
+set -e
+IFS=''
+cat  $XEN_ROOT/config/${XEN_OS}.modules	| (
+	while read l ; do
+		if echo $l | egrep -q "^#" ; then
+			continue
+		fi
+		if echo "$l" | egrep -q "\|" ; then
+			m1=${l%%|*}
+			m2=${l#*|}
+			echo "        modprobe $m1 2>/dev/null || modprobe $m2 2>/dev/null"
+		else
+			echo "        modprobe $l 2>/dev/null"
+		fi
+	done
+) > ${XENCOMMONS_INITD}.modules
+
+cat  ${XENCOMMONS_INITD}.in	| (
+	while read l ; do
+		if echo "$l" | egrep -q "@LOAD_MODULES@" ; then
+			cat ${XENCOMMONS_INITD}.modules
+		else
+			echo $l
+		fi
+	done
+)
+
+rm -f ${XENCOMMONS_INITD}.modules
-- 
2.0.1

[PATCH v8 5/6] autoconf: xen: enable explicit preference option for xenstored preference

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

As it stands oxenstored will be used by default if ocaml tools are
found, the init system will also try to use oxenstored first if its
found otherwise the cxenstored will be used. Lets simplify the init
script and let users be explicit about the preference through configure.

This adds support to let you be explicit about the xenstored preference,
you can only use one of these two options:

./configure --with-xenstored=xenstored
./configure --with-xenstored=oxenstored

We continue with the old behaviour and default oxenstored will be used
but only if you have ocaml dependencies. Since the xenstored preference
is explicit now and since we require configure substitutions for it we
make use of the AX_XEN_EXPAND_CONFIG() helpers as otherwise substitution
for SBINDIR is not propagated from the top level configuration.

All this allows us to simplify the init script to use the configured
xenstore from the start. We update the sysconfig/default xencommons file
with the paths for the different options though, this can be used by
users to override the default xenstored, this follows the old behaviour
but we now just explicitly provide the full configured paths for users.

As before, changing the xenstore requires a reboot.

In order to help with documentation we update the README with some
details on configure usage refer to the wiki [0] [1] [2] for more elaborate
details.

Since we are now parsing an entry within Paths.mk.in on tools we let
the move the parsing of the file to be the tool's configure.

[0] http://wiki.xen.org/wiki/Xenstored
[1] http://wiki.xen.org/wiki/XenStore
[2] http://wiki.xen.org/wiki/XenStoreReference

Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 README                                             | 32 +++++++++++++
 m4/xenstored.m4                                    | 56 ++++++++++++++++++++++
 tools/configure.ac                                 | 19 ++++++--
 ...ysconfig.xencommons => sysconfig.xencommons.in} | 13 ++++-
 .../init.d/{xencommons.in => xencommons.in.in}     |  8 +---
 5 files changed, 117 insertions(+), 11 deletions(-)
 create mode 100644 m4/xenstored.m4
 rename tools/hotplug/Linux/init.d/{sysconfig.xencommons => sysconfig.xencommons.in} (63%)
 rename tools/hotplug/Linux/init.d/{xencommons.in => xencommons.in.in} (92%)

diff --git a/README b/README
index 0c8c7aa..7c27fbb 100644
--- a/README
+++ b/README
@@ -129,6 +129,38 @@ performed with root privileges.]
    versions of those scripts, so that you can copy the dist directory
    to another machine and install from that distribution.
 
+xenstore: xenstored and oxenstored
+====================================
+
+Xen uses a configuration database called xenstore [0] to maintain configuration
+and status information shared between domains. A daemon is implemented as part
+of xenstore to act as an interface for access to the database for dom0 and
+guests. Two xenstored daemons are supported, one written in C which we refer
+to as the xenstored (sometimes referred to as cxenstored), and another written
+in Ocaml called oxenstored. Details for xenstore and the different
+implementations can be found on the wiki's xenstore reference guide [1] and
+the xenstored [2] page. You can choose which xenstore you want to enable as
+default on a system through configure:
+
+	./configure --with-xenstored=xenstored
+	./configure --with-xenstored=oxenstored
+
+By default oxenstored will be used if the ocaml development tools are found.
+If you enable oxenstored the xenstored will still be built and installed,
+the xenstored used can be changed through the configuration file:
+
+/etc/sysconfig/xencommons
+or
+/etc/default/xencommons
+
+You can change the preferred xenstored you want to use in the configuration
+but since we cannot stop the daemon a reboot will be required to make the
+change take effect.
+
+[0] http://wiki.xen.org/wiki/XenStore
+[1] http://wiki.xen.org/wiki/XenStoreReference
+[2] http://wiki.xen.org/wiki/Xenstored
+
 Python Runtime Libraries
 ========================
 
diff --git a/m4/xenstored.m4 b/m4/xenstored.m4
new file mode 100644
index 0000000..30b44c9
--- /dev/null
+++ b/m4/xenstored.m4
@@ -0,0 +1,56 @@
+AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
+	AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
+		AC_MSG_ERROR([Missing ocaml dependencies for oxenstored, try installing ocaml ocaml-compiler-libs ocaml-runtime ocaml-findlib])
+	])
+])
+
+AC_DEFUN([AX_XEN_OCAML_XENSTORE_DEFAULTS], [
+	xenstore="oxenstored"
+	xenstored=$SBINDIR/oxenstored
+	AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
+		xenstore="xenstored"
+		xenstored=$SBINDIR/xenstored
+	])
+])
+
+AC_DEFUN([AX_XENSTORE_OPTIONS], [
+AS_IF([test "x$XENSTORE" = "x"], [
+AC_ARG_WITH([xenstored],
+	AS_HELP_STRING([--with-xenstored@<:@=oxenstored|xenstored@:>@],
+		[This lets you choose which xenstore daemon you want, you have
+		two options: the original xenstored written in C (xenstored)
+		or the newer and robust one written in Ocaml (oxenstored).
+		The oxenstored daemon is the default but will but can only
+		be used if you have ocaml library / build dependencies solved,
+		if you have not specified a preference and do not have ocaml
+		dependencies resolved we'll enable the C xenstored for you. If
+		you ask for oxenstored we'll complain until you resolve those
+		dependencies]),
+	[
+		AS_IF([test "x$withval" = "xxenstored"], [
+			xenstore=$withval
+			xenstored=$SBINDIR/xenstored
+		])
+		AS_IF([test "x$withval" = "xoxenstored"], [
+			xenstore=$withval
+			xenstored=$SBINDIR/oxenstored
+			AX_XEN_OCAML_XENSTORE_CHECK()
+		])
+		AS_IF([test "x$withval" != "xoxenstored" && test "x$withval" != "xxenstored"], [
+			AC_MSG_ERROR([Unsupported xenstored specified, supported types: oxenstored xenstored])
+		])
+	],
+	[
+		AX_XEN_OCAML_XENSTORE_DEFAULTS()
+	])
+])
+])
+
+AC_DEFUN([AX_XENSTORE_SET], [
+	XENSTORE=$xenstore
+
+	AS_IF([test "x$XENSTORED" = "x"], [
+		XENSTORED=$xenstored
+	])
+	AC_SUBST(XENSTORED)
+])
diff --git a/tools/configure.ac b/tools/configure.ac
index 629d6a0..e74fe4b 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -5,7 +5,11 @@ AC_PREREQ([2.67])
 AC_INIT([Xen Hypervisor Tools], m4_esyscmd([../version.sh ../xen/Makefile]),
     [xen-devel@lists.xen.org], [xen], [http://www.xen.org/])
 AC_CONFIG_SRCDIR([libxl/libxl.c])
-AC_CONFIG_FILES([../config/Tools.mk])
+AC_CONFIG_FILES([
+../config/Tools.mk
+hotplug/Linux/init.d/xencommons.in
+hotplug/Linux/init.d/sysconfig.xencommons
+])
 AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_AUX_DIR([../])
 
@@ -53,6 +57,10 @@ m4_include([../m4/ptyfuncs.m4])
 m4_include([../m4/extfs.m4])
 m4_include([../m4/fetcher.m4])
 m4_include([../m4/ax_compare_version.m4])
+m4_include([../m4/paths.m4])
+m4_include([../m4/xenstored.m4])
+
+AX_XEN_EXPAND_CONFIG()
 
 # Enable/disable options
 AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
@@ -203,9 +211,14 @@ AC_PROG_INSTALL
 AC_PATH_PROG([BISON], [bison])
 AC_PATH_PROG([FLEX], [flex])
 AX_PATH_PROG_OR_FAIL([PERL], [perl])
+
+AC_PROG_OCAML
+AC_PROG_FINDLIB
+
+AX_XENSTORE_OPTIONS
+AX_XENSTORE_SET
+
 AS_IF([test "x$ocamltools" = "xy"], [
-    AC_PROG_OCAML
-    AC_PROG_FINDLIB
     AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
         AS_IF([test "x$enable_ocamltools" = "xyes"], [
             AC_MSG_ERROR([Ocaml tools enabled, but unable to find Ocaml])])
diff --git a/tools/hotplug/Linux/init.d/sysconfig.xencommons b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
similarity index 63%
rename from tools/hotplug/Linux/init.d/sysconfig.xencommons
rename to tools/hotplug/Linux/init.d/sysconfig.xencommons.in
index 25f7f00..d423ff8 100644
--- a/tools/hotplug/Linux/init.d/sysconfig.xencommons
+++ b/tools/hotplug/Linux/init.d/sysconfig.xencommons.in
@@ -8,8 +8,17 @@
 ## Type: string
 ## Default: xenstored
 #
-# Select xenstored implementation
-#XENSTORED=[oxenstored|xenstored]
+# Select xenstore implementation, this can be either
+# of these below. If using systemd it's preferred that you
+# just edit the xenstored.service unit file and change
+# the XENSTORED variable there.
+#
+# This can be either of:
+#  * @SBINDIR@/oxenstored
+#  * @SBINDIR@/xenstored
+#
+# Changing this requires a reboot to take effect.
+#XENSTORED=@XENSTORED@
 
 ## Type: string
 ## Default: Not defined, tracing off
diff --git a/tools/hotplug/Linux/init.d/xencommons.in b/tools/hotplug/Linux/init.d/xencommons.in.in
similarity index 92%
rename from tools/hotplug/Linux/init.d/xencommons.in
rename to tools/hotplug/Linux/init.d/xencommons.in.in
index 3939bcc..b311bb8 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in.in
@@ -18,6 +18,8 @@
 # Description:       Starts and stops the daemons neeeded for xl/xend
 ### END INIT INFO
 
+XENSTORED=@XENSTORED@
+
 . /etc/xen/scripts/hotplugpath.sh
 
 if [ -d /etc/sysconfig ]; then
@@ -69,12 +71,6 @@ do_start () {
 		if [ -n "$XENSTORED" ] ; then
 		    echo -n Starting $XENSTORED...
 		    $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		elif [ -x ${SBINDIR}/oxenstored ] ; then
-		    echo -n Starting oxenstored...
-		    ${SBINDIR}/oxenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
-		elif [ -x ${SBINDIR}/xenstored ] ; then
-		    echo -n Starting C xenstored...
-		    ${SBINDIR}/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
 		else
 		    echo "No xenstored found"
 		    exit 1
-- 
2.0.1

[PATCH v8 6/6] systemd: add xen systemd service and module files

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This adds the systemd xen service / module files and integrates
support into the build system.

This goes in with AX_AVAILABLE_SYSTEMD() which will enable
systemd if development libraries have been found on your
build system. If you don't have systemd on target systems
for binaries built with systemd then the binary will not
work, you must explicitly disable systemd support if you
do not want to build systemd support.

When systemd libraries are present only systems that
have booted into systemd go through the systemd initialization,
otherwise the SysVinit is used.

These are originally based on the Fedora systemd files.

Changes made from Fedora's systemd files:

  * split sockets into two files to claim different permissions
  * Use /bin/sh -c exec to for a simple launcher implementation
  * enables systemd socket activation for C xenstored and Ocaml
    oxenstored
  * use sd_notify(), so change the service to Type=notify, because of
    this we remove the PIDFile specification as we don't care for it, and let
    systemd do its magic for us, this also means we don't have to fork
    so we use --no-fork with systemd
  * defines a modules-load.d, its original source file will be shared
    between systemd and old init systems
  * simplify service files with ConditionVirtualization=xen which uses
    the built in systemd virtualization backend detection, these
    service files will not be available to start on systems that do not
    boot with xen as a hypervisor
  * use autoconf to replace @variable@ paths for us which piggy
    backs on top of the latest autoconf changes to xen
  * removes oxenstored service file in favor of a system variable which
    controls which which xentored to use at run time, we avoid multiple
    service files this way.
  * simplifies startup to not require polling on the sockets
    as initial socket management is handled by systemd, we just
    take on the socket later once anything pokes at it, a simple nc -U
    (as root) on any of the sockets files can activate the service for example.
    Anything queued up will be sent to us once we start. Socket activation
    should in theory also let us dynamically switch between xenstores but more
    importantly we could upgrade xenstored while keeping all active
    socket communication queued up, but in order to take advantage of
    this we eventually would need to remove the requirement of not being
    able to bring down the xenstored. Even though active sockets are
    supported since most libxl communication doesn't triggger a check
    on the unix socket first administrators are encouraged to enable
    the xenstored.service to triggger an initialization of the xenstored
    upon bring up. Some systems also never use unix sockets for
    communication with the xenstored and as such active sockets will
    not be used there.
  * allow for xenstored configuration through *either* of these
    configuration files:
	- /etc/sysconfig/xenstored
	- /etc/default/xenstored
    The /etc/default/xenstored will let debian based systems do
    the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
    with sysconfig. We leave these files all commented out by default
    though given that for systemd we want to encourage not using them.
  * ensures we create the run directory as most systems will likely
    be using a tmpfs for run dirs for the pid files
  * Some systems define the selinux context in the systemd Option for the
    /var/lib/xenstored tmpfs:
	Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
    For the upstream version we remove that and let systems specify the
    context on their system /etc/default/xenstored or /etc/sysconfig/xenstored
    $XENSTORED_MOUNT_CTX variable, with a default to none.
  * takes advantage of the shared xendomains helper for the xendomains
    service
  * Add the new dom0 that gets kicked off for disk backend access into
    its own systemd service associated to xen

We end up with these systemd files:

General requirements:

  * proc-xen.mount
  * var-lib-xenstored.mount

xenstored:

  * xenstored.service
  * xenstored.socket
  * xenstored_ro.socket
  * xenconsoled.service
  * xen-qemu-dom0-disk-backend.service.in

Optional:

  * xendomains.service
  * xen-watchdog.service

As for integration with xen, we house keep all the systemd files
under a new directory tools/hotplug/Linux/systemd/ and will be targeted
by default when building on Linux systems if systemd development
libraries are present at build time.

The systemd files will be sanitized for meta @VARIABLES@ upon
configuration and installed upon the install target. Systems that
do not use systemd can still get systemd service unit files installed
if the build system enabled systemd support, this however does not
mandate a requirement of having systemd libraries present. Old init
scripts are always installed.

If you don't specify a prefix you will end up with the services
files under /usr/local/lib/systemd/system/ by default, and systemd
modules-load.d conf files under /usr/local/lib/modules-load.d/ which
systemd does look for (although it seems this is not documented).

Distributions are expected to provide their /usr/ prefix to end up in
the more generic location upon distribution install at
/usr/lib/systemd/system/ and /usr/lib/modules-load.d/ respectively.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Rękorajski <baggins@pld-linux.org>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Jacek Konieczny <jajcus@jajcus.net>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 .gitignore                                         |   5 +
 Makefile                                           |   6 +-
 README                                             |  16 +++
 config/Tools.mk.in                                 |   6 +
 m4/README.source                                   |   8 ++
 m4/systemd.m4                                      | 123 +++++++++++++++++++++
 tools/configure.ac                                 |  11 ++
 tools/hotplug/Linux/Makefile                       |   8 +-
 tools/hotplug/Linux/systemd/Makefile               |  67 +++++++++++
 tools/hotplug/Linux/systemd/proc-xen.mount.in      |   9 ++
 .../Linux/systemd/var-lib-xenstored.mount.in       |  13 +++
 .../systemd/xen-qemu-dom0-disk-backend.service.in  |  22 ++++
 .../hotplug/Linux/systemd/xen-watchdog.service.in  |  13 +++
 tools/hotplug/Linux/systemd/xenconsoled.service.in |  20 ++++
 tools/hotplug/Linux/systemd/xendomains.service.in  |  16 +++
 tools/hotplug/Linux/systemd/xenstored.service.in   |  27 +++++
 tools/hotplug/Linux/systemd/xenstored.socket.in    |  11 ++
 tools/hotplug/Linux/systemd/xenstored_ro.socket.in |  11 ++
 tools/ocaml/xenstored/Makefile                     |   5 +
 tools/xenstore/Makefile                            |   6 +
 20 files changed, 399 insertions(+), 4 deletions(-)
 create mode 100644 m4/systemd.m4
 create mode 100644 tools/hotplug/Linux/systemd/Makefile
 create mode 100644 tools/hotplug/Linux/systemd/proc-xen.mount.in
 create mode 100644 tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
 create mode 100644 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xen-watchdog.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xenconsoled.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xendomains.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xenstored.service.in
 create mode 100644 tools/hotplug/Linux/systemd/xenstored.socket.in
 create mode 100644 tools/hotplug/Linux/systemd/xenstored_ro.socket.in

diff --git a/.gitignore b/.gitignore
index f1d1b9c..6d725aa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -353,3 +353,8 @@ tools/xenstore/xenstore-watch
 docs/txt/misc/*.txt
 docs/txt/man/*.txt
 docs/figs/*.png
+
+tools/hotplug/Linux/systemd/*.conf
+tools/hotplug/Linux/systemd/*.mount
+tools/hotplug/Linux/systemd/*.socket
+tools/hotplug/Linux/systemd/*.service
diff --git a/Makefile b/Makefile
index 41dabbf..580df64 100644
--- a/Makefile
+++ b/Makefile
@@ -216,8 +216,12 @@ uninstall:
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xen-backend.rules
 	rm -f  $(D)$(CONFIG_DIR)/udev/rules.d/xend.rules
 	rm -f  $(D)$(SYSCONFIG_DIR)/xendomains
+	rm -f  $(D)$(SBINDIR)/xendomains
 	rm -f  $(D)$(SYSCONFIG_DIR)/xencommons
-	rm -rf $(D)/var/run/xen* $(D)/var/lib/xen*
+	rm -f  $(D)$(XEN_SYSTEMD_DIR)/*.service
+	rm -f  $(D)$(XEN_SYSTEMD_DIR)/*.mount
+	rm -f  $(D)$(XEN_SYSTEMD_MODULES_LOAD)/*.conf
+	rm -rf $(D)$(XEN_RUN_DIR)* $(D)/var/lib/xen*
 	make -C tools uninstall
 	rm -rf $(D)/boot/tboot*
 
diff --git a/README b/README
index 7c27fbb..81bf938 100644
--- a/README
+++ b/README
@@ -72,6 +72,7 @@ disabled at compile time:
     * cmake (if building vtpm stub domains)
     * markdown
     * figlet (for generating the traditional Xen start of day banner)
+    * systemd daemon development files
 
 Second, you need to acquire a suitable kernel for use in domain 0. If
 possible you should use a kernel provided by your OS distributor. If
@@ -161,6 +162,21 @@ change take effect.
 [1] http://wiki.xen.org/wiki/XenStoreReference
 [2] http://wiki.xen.org/wiki/Xenstored
 
+Systemd support
+===============
+
+If you have systemd development packages installed you can build binaries
+with systemd support. Systemd support is enabled by default if you have
+systemd development libraries present. If you want to force enable systemd to
+ensure you build binaries with systemd support you can use the --enable-systemd
+flag. Likewise if you want to force disable systemd you can use:
+
+	./configure --disable-systemd
+
+For more details refer to the xen xenstored systemd wiki page [3].
+
+[3] http://wiki.xen.org/wiki/Xenstored#xenstored_systemd_support
+
 Python Runtime Libraries
 ========================
 
diff --git a/config/Tools.mk.in b/config/Tools.mk.in
index 748cc69..974e28e 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -63,6 +63,12 @@ CONFIG_BLKTAP2      := @blktap2@
 CONFIG_VTPM         := @vtpm@
 CONFIG_QEMUU_EXTRA_ARGS:= @EXTRA_QEMUU_CONFIGURE_ARGS@
 
+CONFIG_SYSTEMD      := @systemd@
+SYSTEMD_CFLAGS      := @SYSTEMD_CFLAGS@
+SYSTEMD_LIBS        := @SYSTEMD_LIBS@
+XEN_SYSTEMD_DIR     := @SYSTEMD_DIR@
+XEN_SYSTEMD_MODULES_LOAD := @SYSTEMD_MODULES_LOAD@
+
 #System options
 ZLIB                := @zlib@
 CONFIG_LIBICONV     := @libiconv@
diff --git a/m4/README.source b/m4/README.source
index 8922ea0..21850a6 100644
--- a/m4/README.source
+++ b/m4/README.source
@@ -26,3 +26,11 @@ Date:   Mon Feb 3 15:59:18 2014 -0800
     With the newly added glib.mk, some of the noinst_* variables need to use
     += in the evaluation to avoid multiple definition warnings from
     automake.
+
+systemd.m4
+==========
+
+systemd.m4 was contributed to by Luis R. Rodriguez <mcgrof@do-not-panic.com>,
+its current home project can be found at:
+
+https://github.com/mcgrof/funk-systemd
diff --git a/m4/systemd.m4 b/m4/systemd.m4
new file mode 100644
index 0000000..760bbad
--- /dev/null
+++ b/m4/systemd.m4
@@ -0,0 +1,123 @@
+# systemd.m4 - Macros to check for and enable systemd          -*- Autoconf -*-
+#
+# Copyright (C) 2014 Luis R. Rodriguez <mcgrof@suse.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+
+dnl Some optional path options
+AC_DEFUN([AX_SYSTEMD_OPTIONS], [
+	AC_ARG_WITH(systemd, [  --with-systemd          set directory for systemd service files],
+		SYSTEMD_DIR="$withval", SYSTEMD_DIR="")
+	AC_SUBST(SYSTEMD_DIR)
+
+	AC_ARG_WITH(systemd, [  --with-systemd-modules-load          set directory for systemd modules load files],
+		SYSTEMD_MODULES_LOAD="$withval", SYSTEMD_MODULES_LOAD="")
+	AC_SUBST(SYSTEMD_MODULES_LOAD)
+])
+
+AC_DEFUN([AX_ENABLE_SYSTEMD_OPTS], [
+	AX_ARG_DEFAULT_ENABLE([systemd], [Disable systemd support])
+	AX_SYSTEMD_OPTIONS()
+])
+
+AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
+	AX_ARG_DEFAULT_DISABLE([systemd], [Enable systemd support])
+	AX_SYSTEMD_OPTIONS()
+])
+
+AC_DEFUN([AX_CHECK_SYSTEMD_LIBS], [
+	AC_CHECK_HEADER([systemd/sd-daemon.h], [
+	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [libsystemddaemon="y"])
+	])
+	AS_IF([test "x$libsystemddaemon" = x], [
+	    AC_MSG_ERROR([Unable to find a suitable libsystemd-daemon library])
+	])
+
+	PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
+	dnl pkg-config older than 0.24 does not set these for
+	dnl PKG_CHECK_MODULES() worth also noting is that as of version 208
+	dnl of systemd pkg-config --cflags currently yields no extra flags yet.
+	AC_SUBST([SYSTEMD_CFLAGS])
+	AC_SUBST([SYSTEMD_LIBS])
+
+	AS_IF([test "x$SYSTEMD_DIR" = x], [
+	    dnl In order to use the line below we need to fix upstream systemd
+	    dnl to properly ${prefix} for child variables in
+	    dnl src/core/systemd.pc.in but this is a bit complex at the
+	    dnl moment as they depend on another rootprefix, which can vary
+	    dnl from prefix in practice. We provide our own definition as we
+	    dnl *know* where systemd will dump this to, but this does limit
+	    dnl us to stick to a non custom systemdsystemunitdir, to work
+	    dnl around this we provide the additional configure option
+	    dnl --with-systemd where you can specify the directory for the unit
+	    dnl files. It would also be best to just extend the upstream
+	    dnl pkg-config  pkg.m4 with an AC_DEFUN() to do this neatly.
+	    dnl SYSTEMD_DIR="`$PKG_CONFIG --define-variable=prefix=$PREFIX --variable=systemdsystemunitdir systemd`"
+	    SYSTEMD_DIR="\$(prefix)/lib/systemd/system/"
+	], [])
+
+	AS_IF([test "x$SYSTEMD_DIR" = x], [
+	    AC_MSG_ERROR([SYSTEMD_DIR is unset])
+	], [])
+
+	dnl There is no variable for this yet for some reason
+	AS_IF([test "x$SYSTEMD_MODULES_LOAD" = x], [
+	    SYSTEMD_MODULES_LOAD="\$(prefix)/lib/modules-load.d/"
+	], [])
+
+	AS_IF([test "x$SYSTEMD_MODULES_LOAD" = x], [
+	    AC_MSG_ERROR([SYSTEMD_MODULES_LOAD is unset])
+	], [])
+])
+
+AC_DEFUN([AX_CHECK_SYSTEMD], [
+	dnl Respect user override to disable
+	AS_IF([test "x$enable_systemd" != "xno"], [
+	     AS_IF([test "x$systemd" = "xy" ], [
+		AC_DEFINE([HAVE_SYSTEMD], [1], [Systemd available and enabled])
+			systemd=y
+			AX_CHECK_SYSTEMD_LIBS()
+	    ],[systemd=n])
+	],[systemd=n])
+])
+
+AC_DEFUN([AX_CHECK_SYSTEMD_ENABLE_AVAILABLE], [
+	AC_CHECK_HEADER([systemd/sd-daemon.h], [
+	    AC_CHECK_LIB([systemd-daemon], [sd_listen_fds], [systemd="y"])
+	])
+])
+
+dnl Enables systemd by default and requires a --disable-systemd option flag
+dnl to configure if you want to disable.
+AC_DEFUN([AX_ENABLE_SYSTEMD], [
+	AX_ENABLE_SYSTEMD_OPTS()
+	AX_CHECK_SYSTEMD()
+])
+
+dnl Systemd will be disabled by default and requires you to run configure with
+dnl --enable-systemd to look for and enable systemd.
+AC_DEFUN([AX_ALLOW_SYSTEMD], [
+	AX_ALLOW_SYSTEMD_OPTS()
+	AX_CHECK_SYSTEMD()
+])
+
+dnl Systemd will be disabled by default but if your build system is detected
+dnl to have systemd build libraries it will be enabled. You can always force
+dnl disable with --disable-systemd
+AC_DEFUN([AX_AVAILABLE_SYSTEMD], [
+	AX_ALLOW_SYSTEMD_OPTS()
+	AX_CHECK_SYSTEMD_ENABLE_AVAILABLE()
+	AX_CHECK_SYSTEMD()
+])
diff --git a/tools/configure.ac b/tools/configure.ac
index e74fe4b..f44b9f3 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -9,6 +9,15 @@ AC_CONFIG_FILES([
 ../config/Tools.mk
 hotplug/Linux/init.d/xencommons.in
 hotplug/Linux/init.d/sysconfig.xencommons
+hotplug/Linux/systemd/proc-xen.mount
+hotplug/Linux/systemd/var-lib-xenstored.mount
+hotplug/Linux/systemd/xenstored.socket
+hotplug/Linux/systemd/xenstored_ro.socket
+hotplug/Linux/systemd/xenstored.service
+hotplug/Linux/systemd/xenconsoled.service
+hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service
+hotplug/Linux/systemd/xendomains.service
+hotplug/Linux/systemd/xen-watchdog.service
 ])
 AC_CONFIG_HEADERS([config.h])
 AC_CONFIG_AUX_DIR([../])
@@ -59,6 +68,7 @@ m4_include([../m4/fetcher.m4])
 m4_include([../m4/ax_compare_version.m4])
 m4_include([../m4/paths.m4])
 m4_include([../m4/xenstored.m4])
+m4_include([../m4/systemd.m4])
 
 AX_XEN_EXPAND_CONFIG()
 
@@ -310,5 +320,6 @@ AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h valgrind/memcheck.h utmp.h])
 
 fi # ! $rump
 
+AX_AVAILABLE_SYSTEMD()
 AC_OUTPUT()
 
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index f85e8ab..418cfb5 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -25,6 +25,8 @@ XEN_SCRIPTS += vscsi
 XEN_SCRIPTS += block-iscsi
 XEN_SCRIPTS += $(XEN_SCRIPTS-y)
 
+SUBDIRS-$(CONFIG_SYSTEMD) += systemd
+
 XEN_SCRIPT_DATA = xen-script-common.sh locking.sh logging.sh
 XEN_SCRIPT_DATA += xen-hotplug-common.sh xen-network-common.sh vif-common.sh
 XEN_SCRIPT_DATA += block-common.sh
@@ -33,7 +35,7 @@ UDEV_RULES_DIR = $(CONFIG_DIR)/udev
 UDEV_RULES = xen-backend.rules $(UDEV_RULES-y)
 
 .PHONY: all
-all: $(XENCOMMONS_INITD)
+all: $(XENCOMMONS_INITD) subdirs-all
 
 $(XENCOMMONS_INITD): $(XEN_ROOT)/config/$(XEN_OS).modules $(XENCOMMONS_INITD).in
 	$(XEN_ROOT)/tools/hotplug/Linux/update-modules.sh > $@
@@ -42,7 +44,7 @@ $(XENCOMMONS_INITD): $(XEN_ROOT)/config/$(XEN_OS).modules $(XENCOMMONS_INITD).in
 build: all
 
 .PHONY: install
-install: all install-initd install-scripts install-udev
+install: all install-initd install-scripts install-udev subdirs-install
 
 # See docs/misc/distro_mapping.txt for INITD_DIR location
 .PHONY: install-initd
@@ -80,4 +82,4 @@ install-udev:
 	done
 
 .PHONY: clean
-clean:
+clean: subdirs-clean
diff --git a/tools/hotplug/Linux/systemd/Makefile b/tools/hotplug/Linux/systemd/Makefile
new file mode 100644
index 0000000..dc98b67
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/Makefile
@@ -0,0 +1,67 @@
+XEN_ROOT = $(CURDIR)/../../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+XEN_SYSTEMD_MODULES = xen.conf
+
+XEN_SYSTEMD_MOUNT =  proc-xen.mount
+XEN_SYSTEMD_MOUNT += var-lib-xenstored.mount
+
+XEN_SYSTEMD_SOCKET  = xenstored.socket
+XEN_SYSTEMD_SOCKET += xenstored_ro.socket
+
+XEN_SYSTEMD_SERVICE  = xenstored.service
+XEN_SYSTEMD_SERVICE += xenconsoled.service
+XEN_SYSTEMD_SERVICE += xen-qemu-dom0-disk-backend.service
+XEN_SYSTEMD_SERVICE += xendomains.service
+XEN_SYSTEMD_SERVICE += xen-watchdog.service
+
+ALL_XEN_SYSTEMD =	$(XEN_SYSTEMD_MODULES)  \
+			$(XEN_SYSTEMD_MOUNT)	\
+			$(XEN_SYSTEMD_SOCKET)	\
+			$(XEN_SYSTEMD_SERVICE)
+
+.PHONY: all
+all:	$(ALL_XEN_SYSTEMD)
+
+.PHONY: clean
+clean:
+
+.PHONY: install
+install: $(ALL_XEN_SYSTEMD)
+	[ -d $(DESTDIR)$(XEN_SYSTEMD_DIR) ] || \
+		$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_DIR)
+	[ -d $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD) ] || \
+		$(INSTALL_DIR) $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
+	$(INSTALL_DATA) *.socket $(DESTDIR)$(XEN_SYSTEMD_DIR)
+	$(INSTALL_DATA) *.service $(DESTDIR)$(XEN_SYSTEMD_DIR)
+	$(INSTALL_DATA) *.mount $(DESTDIR)$(XEN_SYSTEMD_DIR)
+	$(INSTALL_DATA) *.conf $(DESTDIR)$(XEN_SYSTEMD_MODULES_LOAD)
+
+$(XEN_SYSTEMD_MODULES): $(XEN_ROOT)/config/$(XEN_OS).modules
+	@set -e ;							\
+	IFS=''								;\
+	cat  $(XEN_ROOT)/config/$(XEN_OS).modules	| (		\
+		while read l ; do					\
+			if echo $${l} | egrep -q "^#" ; then		\
+				continue				;\
+			fi						;\
+			if echo "$${l}" | egrep -q "\|" ; then		\
+				m1=$${l%%|*}				;\
+				m2=$${l#*|} 				;\
+				# Systemd modules-load.d lacks support	;\
+				# for module replacement options, we	;\
+				# need to add that support upstream but ;\
+				# its best instead to ensure this file	;\
+				# is no longer needed. Some folks	;\
+				# however have reported issues with	;\
+				# some modules automatically loading	;\
+				# so we just load all necessary xen	;\
+				# modules and for replacements we load	;\
+				# the latest module			;\
+				echo "$$m1" ;\
+				echo "$$m2" ;\
+			else						\
+				echo "$$l"				;\
+			fi						;\
+		done							\
+	) > $@
diff --git a/tools/hotplug/Linux/systemd/proc-xen.mount.in b/tools/hotplug/Linux/systemd/proc-xen.mount.in
new file mode 100644
index 0000000..f0c4f3a
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/proc-xen.mount.in
@@ -0,0 +1,9 @@
+[Unit]
+Description=Mount /proc/xen files
+ConditionVirtualization=xen
+RefuseManualStop=true
+
+[Mount]
+What=xenfs
+Where=/proc/xen
+Type=xenfs
diff --git a/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
new file mode 100644
index 0000000..44dfce8
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/var-lib-xenstored.mount.in
@@ -0,0 +1,13 @@
+[Unit]
+Description=mount xenstore file system
+ConditionVirtualization=xen
+RefuseManualStop=true
+
+[Mount]
+Environment=XENSTORED_MOUNT_CTX=none
+EnvironmentFile=-/etc/sysconfig/xenstored
+EnvironmentFile=-/etc/default/xenstored
+What=xenstore
+Where=@XEN_LIB_STORED@
+Type=tmpfs
+Options=mode=755,context="$XENSTORED_MOUNT_CTX"
diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
new file mode 100644
index 0000000..8dbd110
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
@@ -0,0 +1,22 @@
+[Unit]
+Description=qemu for xen dom0 disk backend
+Requires=proc-xen.mount var-lib-xenstored.mount xenstored.socket
+After=xenstored.service xenconsoled.service
+Before=xendomains.service libvirtd.service libvirt-guests.service
+RefuseManualStop=true
+ConditionVirtualization=xen
+
+[Service]
+Type=simple
+EnvironmentFile=-/etc/default/xenstored
+EnvironmentFile=-/etc/sysconfig/xenstored
+PIDFile=@XEN_RUN_DIR@/qemu-dom0.pid
+ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
+ExecStartPre=/bin/mkdir -p /var/run/xen
+ExecStart=@LIBEXEC@/qemu-system-i386 -xen-domid 0 \
+	-xen-attach -name dom0 -nographic -M xenpv -daemonize \
+	-monitor /dev/null -serial /dev/null -parallel /dev/null \
+	-pidfile @XEN_RUN_DIR@/qemu-dom0.pid
+
+[Install]
+WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/systemd/xen-watchdog.service.in b/tools/hotplug/Linux/systemd/xen-watchdog.service.in
new file mode 100644
index 0000000..acb2b77
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xen-watchdog.service.in
@@ -0,0 +1,13 @@
+[Unit]
+Description=Xen-watchdog - run xen watchdog daemon
+Requires=proc-xen.mount
+After=proc-xen.mount xendomains.service
+ConditionVirtualization=xen
+
+[Service]
+Type=forking
+ExecStart=@SBINDIR@/xenwatchdogd 30 15
+KillSignal=USR1
+
+[Install]
+WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in b/tools/hotplug/Linux/systemd/xenconsoled.service.in
new file mode 100644
index 0000000..15fad35
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -0,0 +1,20 @@
+[Unit]
+Description=Xenconsoled - handles logging from guest consoles and hypervisor
+Requires=xenstored.socket
+After=xenstored.service
+ConditionVirtualization=xen
+
+[Service]
+Type=simple
+Environment=XENCONSOLED_ARGS=
+Environment=XENCONSOLED_LOG=none
+Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
+EnvironmentFile=-/etc/default/xenconsoled
+EnvironmentFile=-/etc/sysconfig/xenconsoled
+PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
+ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
+ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
+ExecStart=@SBINDIR@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid --log=${XENCONSOLED_LOG} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+
+[Install]
+WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/systemd/xendomains.service.in b/tools/hotplug/Linux/systemd/xendomains.service.in
new file mode 100644
index 0000000..70ce7c0
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xendomains.service.in
@@ -0,0 +1,16 @@
+[Unit]
+Description=Xendomains - start and stop guests on boot and shutdown
+Requires=xenstored.socket
+After=xenstored.service xenconsoled.service
+ConditionVirtualization=xen
+
+[Service]
+Type=oneshot
+RemainAfterExit=true
+ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
+ExecStart=-@LIBEXEC@/xendomains start
+ExecStop=@LIBEXEC@/xendomains stop
+ExecReload=@LIBEXEC@/xendomains restart
+
+[Install]
+WantedBy=multi-user.target
diff --git a/tools/hotplug/Linux/systemd/xenstored.service.in b/tools/hotplug/Linux/systemd/xenstored.service.in
new file mode 100644
index 0000000..4a9fcee
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -0,0 +1,27 @@
+[Unit]
+Description=The Xen xenstore
+Requires=xenstored_ro.socket xenstored.socket proc-xen.mount var-lib-xenstored.mount
+After=proc-xen.mount var-lib-xenstored.mount
+Before=libvirtd.service libvirt-guests.service
+RefuseManualStop=true
+ConditionVirtualization=xen
+
+[Service]
+Type=notify
+Environment=XENSTORED_ARGS=
+Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
+Environment=XENSTORED=@XENSTORED@
+EnvironmentFile=-/etc/default/xencommons
+EnvironmentFile=-/etc/sysconfig/xencommons
+ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
+ExecStartPre=-/bin/rm -f @XEN_LIB_STORED@/tdb*
+ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
+ExecStart=/bin/sh -c "exec $XENSTORED --no-fork $XENSTORED_ARGS"
+ExecStartPost=-@BINDIR@/xenstore-write "/local/domain/0/name" "Domain-0"
+ExecStartPost=-@BINDIR@/xenstore-write "/local/domain/0/domid" 0
+
+[Install]
+WantedBy=multi-user.target
+Also=xenstored_ro.socket xenstored.socket
+Also=proc-xen.mount
+Also=var-lib-xenstored.mount
diff --git a/tools/hotplug/Linux/systemd/xenstored.socket.in b/tools/hotplug/Linux/systemd/xenstored.socket.in
new file mode 100644
index 0000000..461e4f4
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xenstored.socket.in
@@ -0,0 +1,11 @@
+[Unit]
+Description=xenstore socket
+ConditionVirtualization=xen
+
+[Socket]
+ListenStream=/var/run/xenstored/socket
+SocketMode=0600
+Service=xenstored.service
+
+[Install]
+WantedBy=sockets.target
diff --git a/tools/hotplug/Linux/systemd/xenstored_ro.socket.in b/tools/hotplug/Linux/systemd/xenstored_ro.socket.in
new file mode 100644
index 0000000..6ab5c28
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xenstored_ro.socket.in
@@ -0,0 +1,11 @@
+[Unit]
+Description=xenstore ro socket
+ConditionVirtualization=xen
+
+[Socket]
+ListenStream=/var/run/xenstored/socket_ro
+SocketMode=0660
+Service=xenstored.service
+
+[Install]
+WantedBy=sockets.target
diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
index 382a813..068e04a 100644
--- a/tools/ocaml/xenstored/Makefile
+++ b/tools/ocaml/xenstored/Makefile
@@ -3,6 +3,11 @@ OCAML_TOPLEVEL = $(CURDIR)/..
 include $(OCAML_TOPLEVEL)/common.make
 
 CFLAGS += -I$(XEN_ROOT)/tools/
+CFLAGS-$(CONFIG_SYSTEMD)  += $(SYSTEMD_CFLAGS)
+LDFLAGS-$(CONFIG_SYSTEMD) += $(SYSTEMD_LIBS)
+
+CFLAGS  += $(CFLAGS-y)
+LDFLAGS += $(LDFLAGS-y)
 
 OCAMLINCLUDE += \
 	-I $(OCAML_TOPLEVEL)/libs/xb \
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 08460c8..48f1e96 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -9,6 +9,12 @@ CFLAGS += -I.
 CFLAGS += -I$(XEN_ROOT)/tools/
 CFLAGS += $(CFLAGS_libxenctrl)
 
+CFLAGS-$(CONFIG_SYSTEMD)  += $(SYSTEMD_CFLAGS)
+LDFLAGS-$(CONFIG_SYSTEMD) += $(SYSTEMD_LIBS)
+
+CFLAGS  += $(CFLAGS-y)
+LDFLAGS += $(LDFLAGS-y)
+
 CLIENTS := xenstore-exists xenstore-list xenstore-read xenstore-rm xenstore-chmod
 CLIENTS += xenstore-write xenstore-ls xenstore-watch
 
-- 
2.0.1


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

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Here's my v8 series. Quite a bit of patches are alreayd merged
> on the xen origin/staging branch, this addresses the last feedback
> from the v7 series and is rebased. It contains two fixes spotted
> as possible issues by Ian Campbell.
> 
> I think this is it, after about 2 months of spinning patches. Phew.

I was about to ack and apply the lot when I noticed that
dist/install/etc/init.d/xencommons was an empty file. I didn't analyse
which patch it was, but I guessed at "move module list into a generic
place" and reverting to the patch before that worked, so I've pushed
just those, specifically:

54f2891 autoconf: xen: move standard path variables to config/Paths.mk
1846031 oxenstored: also fail if only 1 socket was given by systemd
bdc74c9 cxenstored: also fail if only 1 socket was given by systemd

I'm a little concerned by the recent lack of comments from systemd folks
on the final patch, but there didn't seem much benefit in waiting any
longer. Presumably any issues will get shaken down as people test etc.

Thanks!

Ian.

Re: [PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

On Mon, Jul 28, 2014 at 01:46:32PM +0100, Ian Campbell wrote:
> On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Here's my v8 series. Quite a bit of patches are alreayd merged
> > on the xen origin/staging branch, this addresses the last feedback
> > from the v7 series and is rebased. It contains two fixes spotted
> > as possible issues by Ian Campbell.
> > 
> > I think this is it, after about 2 months of spinning patches. Phew.
> 
> I was about to ack and apply the lot when I noticed that
> dist/install/etc/init.d/xencommons was an empty file.

The file tools/hotplug/Linux/update-modules.sh must be chmod 755
and I thought I did that on the series, I just double checked and
it is indeed in the right mode on the v8 patch so not sure what
could have gone wrong here. Sorry about that I could have sworn
I had tested that particular case... I'm pretty sure I did. Will
reseting / poke around.

  Luis

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Mon, 2014-07-28 at 17:02 +0200, Luis R. Rodriguez wrote:
> On Mon, Jul 28, 2014 at 01:46:32PM +0100, Ian Campbell wrote:
> > On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > 
> > > Here's my v8 series. Quite a bit of patches are alreayd merged
> > > on the xen origin/staging branch, this addresses the last feedback
> > > from the v7 series and is rebased. It contains two fixes spotted
> > > as possible issues by Ian Campbell.
> > > 
> > > I think this is it, after about 2 months of spinning patches. Phew.
> > 
> > I was about to ack and apply the lot when I noticed that
> > dist/install/etc/init.d/xencommons was an empty file.
> 
> The file tools/hotplug/Linux/update-modules.sh must be chmod 755

I observed the git diff had the mode in it, so I assumed that git am
would have done the right thing. I didn't check directly but I did look
at the build log which didn't show it failing to run the script (which
in any case should have caused the build to fail)

> and I thought I did that on the series, I just double checked and
> it is indeed in the right mode on the v8 patch so not sure what
> could have gone wrong here. Sorry about that I could have sworn
> I had tested that particular case... I'm pretty sure I did. Will
> reseting / poke around.

Thanks.

Ian.

Re: [PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

On Mon, Jul 28, 2014 at 04:05:51PM +0100, Ian Campbell wrote:
> On Mon, 2014-07-28 at 17:02 +0200, Luis R. Rodriguez wrote:
> > On Mon, Jul 28, 2014 at 01:46:32PM +0100, Ian Campbell wrote:
> > > On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > 
> > > > Here's my v8 series. Quite a bit of patches are alreayd merged
> > > > on the xen origin/staging branch, this addresses the last feedback
> > > > from the v7 series and is rebased. It contains two fixes spotted
> > > > as possible issues by Ian Campbell.
> > > > 
> > > > I think this is it, after about 2 months of spinning patches. Phew.
> > > 
> > > I was about to ack and apply the lot when I noticed that
> > > dist/install/etc/init.d/xencommons was an empty file.
> > 
> > The file tools/hotplug/Linux/update-modules.sh must be chmod 755
> 
> I observed the git diff had the mode in it, so I assumed that git am
> would have done the right thing. I didn't check directly but I did look
> at the build log which didn't show it failing to run the script (which
> in any case should have caused the build to fail)
> 
> > and I thought I did that on the series, I just double checked and
> > it is indeed in the right mode on the v8 patch so not sure what
> > could have gone wrong here. Sorry about that I could have sworn
> > I had tested that particular case... I'm pretty sure I did. Will
> > reseting / poke around.
> 
> Thanks.

OK I see now what happed. In my tests I had exported XENCOMMONS_INITD
locally to run and test the shell script from the shell and later
make -C tools/hotplug/Linux. This worked as I exported it manually but
without that we need to expicitly do that then on the Makefile now or
pass it as an argument. Exporting seems easier. Will rebase and send
last batch with this hunk merged.

diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 418cfb5..12342e4 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -6,7 +6,7 @@ XENDOMAINS_INITD = init.d/xendomains
 XENDOMAINS_LIBEXEC = xendomains
 XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
 
-XENCOMMONS_INITD = init.d/xencommons
+export XENCOMMONS_INITD = init.d/xencommons
 XENCOMMONS_SYSCONFIG = init.d/sysconfig.xencommons
 
 # Xen script dir and scripts to go there.

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Mon, 2014-07-28 at 19:57 +0200, Luis R. Rodriguez wrote:
> On Mon, Jul 28, 2014 at 04:05:51PM +0100, Ian Campbell wrote:
> > On Mon, 2014-07-28 at 17:02 +0200, Luis R. Rodriguez wrote:
> > > On Mon, Jul 28, 2014 at 01:46:32PM +0100, Ian Campbell wrote:
> > > > On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > 
> > > > > Here's my v8 series. Quite a bit of patches are alreayd merged
> > > > > on the xen origin/staging branch, this addresses the last feedback
> > > > > from the v7 series and is rebased. It contains two fixes spotted
> > > > > as possible issues by Ian Campbell.
> > > > > 
> > > > > I think this is it, after about 2 months of spinning patches. Phew.
> > > > 
> > > > I was about to ack and apply the lot when I noticed that
> > > > dist/install/etc/init.d/xencommons was an empty file.
> > > 
> > > The file tools/hotplug/Linux/update-modules.sh must be chmod 755
> > 
> > I observed the git diff had the mode in it, so I assumed that git am
> > would have done the right thing. I didn't check directly but I did look
> > at the build log which didn't show it failing to run the script (which
> > in any case should have caused the build to fail)
> > 
> > > and I thought I did that on the series, I just double checked and
> > > it is indeed in the right mode on the v8 patch so not sure what
> > > could have gone wrong here. Sorry about that I could have sworn
> > > I had tested that particular case... I'm pretty sure I did. Will
> > > reseting / poke around.
> > 
> > Thanks.
> 
> OK I see now what happed. In my tests I had exported XENCOMMONS_INITD
> locally to run and test the shell script from the shell and later
> make -C tools/hotplug/Linux. This worked as I exported it manually but
> without that we need to expicitly do that then on the Makefile now or
> pass it as an argument. Exporting seems easier. Will rebase and send
> last batch with this hunk merged.

I'd prefer the script to take this as an argument for clarity.

Also, you should probably invoke the script with $(BASH), else IIRC you
will break *BSD (where bash is in ports not /bin)

Ian.

Re: [PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

On Tue, Jul 29, 2014 at 09:56:39AM +0100, Ian Campbell wrote:
> On Mon, 2014-07-28 at 19:57 +0200, Luis R. Rodriguez wrote:
> > On Mon, Jul 28, 2014 at 04:05:51PM +0100, Ian Campbell wrote:
> > > On Mon, 2014-07-28 at 17:02 +0200, Luis R. Rodriguez wrote:
> > > > On Mon, Jul 28, 2014 at 01:46:32PM +0100, Ian Campbell wrote:
> > > > > On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > > 
> > > > > > Here's my v8 series. Quite a bit of patches are alreayd merged
> > > > > > on the xen origin/staging branch, this addresses the last feedback
> > > > > > from the v7 series and is rebased. It contains two fixes spotted
> > > > > > as possible issues by Ian Campbell.
> > > > > > 
> > > > > > I think this is it, after about 2 months of spinning patches. Phew.
> > > > > 
> > > > > I was about to ack and apply the lot when I noticed that
> > > > > dist/install/etc/init.d/xencommons was an empty file.
> > > > 
> > > > The file tools/hotplug/Linux/update-modules.sh must be chmod 755
> > > 
> > > I observed the git diff had the mode in it, so I assumed that git am
> > > would have done the right thing. I didn't check directly but I did look
> > > at the build log which didn't show it failing to run the script (which
> > > in any case should have caused the build to fail)
> > > 
> > > > and I thought I did that on the series, I just double checked and
> > > > it is indeed in the right mode on the v8 patch so not sure what
> > > > could have gone wrong here. Sorry about that I could have sworn
> > > > I had tested that particular case... I'm pretty sure I did. Will
> > > > reseting / poke around.
> > > 
> > > Thanks.
> > 
> > OK I see now what happed. In my tests I had exported XENCOMMONS_INITD
> > locally to run and test the shell script from the shell and later
> > make -C tools/hotplug/Linux. This worked as I exported it manually but
> > without that we need to expicitly do that then on the Makefile now or
> > pass it as an argument. Exporting seems easier. Will rebase and send
> > last batch with this hunk merged.
> 
> I'd prefer the script to take this as an argument for clarity.

OK done.

> Also, you should probably invoke the script with $(BASH), else IIRC you
> will break *BSD (where bash is in ports not /bin)
> 
> Ian.

This is a Linux script though, I'll use  #!/usr/bin/env bash
instead then.

  Luis

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Wed, 2014-07-30 at 18:22 +0200, Luis R. Rodriguez wrote:

> > Also, you should probably invoke the script with $(BASH), else IIRC you
> > will break *BSD (where bash is in ports not /bin)

> This is a Linux script though,

True.

>  I'll use  #!/usr/bin/env bash
> instead then.

That's worse than either $(BASH) or a normal #! IMHO.

Ian

Re: [PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

On Wed, Jul 30, 2014 at 05:25:40PM +0100, Ian Campbell wrote:
> On Wed, 2014-07-30 at 18:22 +0200, Luis R. Rodriguez wrote:
> 
> > > Also, you should probably invoke the script with $(BASH), else IIRC you
> > > will break *BSD (where bash is in ports not /bin)
> 
> > This is a Linux script though,
> 
> True.
> 
> >  I'll use  #!/usr/bin/env bash
> > instead then.
> 
> That's worse than either $(BASH) or a normal #! IMHO.

Do you mean to call $BASH foo.sh on the makefile ?
On Linux we can run scripts often on Makefiles with
either #!/bin/bash or the env thing just fine. I've
never actually have seen the use of $(BASH) foo.sh
within the Makefile. I promise to address issues
if found with this approach.

  Luis

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Wed, 2014-07-30 at 18:43 +0200, Luis R. Rodriguez wrote:
> On Wed, Jul 30, 2014 at 05:25:40PM +0100, Ian Campbell wrote:
> > On Wed, 2014-07-30 at 18:22 +0200, Luis R. Rodriguez wrote:
> > 
> > > > Also, you should probably invoke the script with $(BASH), else IIRC you
> > > > will break *BSD (where bash is in ports not /bin)
> > 
> > > This is a Linux script though,
> > 
> > True.
> > 
> > >  I'll use  #!/usr/bin/env bash
> > > instead then.
> > 
> > That's worse than either $(BASH) or a normal #! IMHO.
> 
> Do you mean to call $BASH foo.sh on the makefile ?

I meant $(BASH), or perhaps $(SHELL), but yes.

> On Linux we can run scripts often on Makefiles with
> either #!/bin/bash or the env thing just fine. I've
> never actually have seen the use of $(BASH) foo.sh
> within the Makefile.

Yes, it seems like you are right and we don't do this. I suppose because
all such #! lines are in Linux specific bits of the build. Sorry, I
guess I was confused by the presence of $(BASH) at all, combined with
the fact that we do jump through similar hoops for $(PYTHON).

So lets leave it as #! /bin/bash which appears to be the predominant
style.

>  I promise to address issues
> if found with this approach.

Thanks.

Ian.

Re: [PATCH v8 0/6] xen: systemd support

[Andrew Cooper]

On 28/07/14 13:46, Ian Campbell wrote:
> On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> Here's my v8 series. Quite a bit of patches are alreayd merged
>> on the xen origin/staging branch, this addresses the last feedback
>> from the v7 series and is rebased. It contains two fixes spotted
>> as possible issues by Ian Campbell.
>>
>> I think this is it, after about 2 months of spinning patches. Phew.
> I was about to ack and apply the lot when I noticed that
> dist/install/etc/init.d/xencommons was an empty file. I didn't analyse
> which patch it was, but I guessed at "move module list into a generic
> place" and reverting to the patch before that worked, so I've pushed
> just those, specifically:
>
> 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
> 1846031 oxenstored: also fail if only 1 socket was given by systemd
> bdc74c9 cxenstored: also fail if only 1 socket was given by systemd
>
> I'm a little concerned by the recent lack of comments from systemd folks
> on the final patch, but there didn't seem much benefit in waiting any
> longer. Presumably any issues will get shaken down as people test etc.
>
> Thanks!
>
> Ian.

54f2891 autoconf: xen: move standard path variables to config/Paths.mk

has caused quite a lot of collateral damage on my dev tree.  Cheif
amongst the problems is:

andrewcoop@andrewcoop:/local/xen.git/tools$ make clean
/local/xen.git/tools/../tools/Rules.mk:8:
/local/xen.git/tools/../config/Paths.mk: No such file or directory
make: *** No rule to make target
`/local/xen.git/tools/../config/Paths.mk'.  Stop.

Running ./configure (without any arguments) does not generate Paths.mk
from Paths.mk.in, which means that I still cant `make clean`

~Andrew

Re: [PATCH v8 0/6] xen: systemd support

[Andrew Cooper]

On 28/07/14 17:52, Andrew Cooper wrote:
> On 28/07/14 13:46, Ian Campbell wrote:
>> On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>
>>> Here's my v8 series. Quite a bit of patches are alreayd merged
>>> on the xen origin/staging branch, this addresses the last feedback
>>> from the v7 series and is rebased. It contains two fixes spotted
>>> as possible issues by Ian Campbell.
>>>
>>> I think this is it, after about 2 months of spinning patches. Phew.
>> I was about to ack and apply the lot when I noticed that
>> dist/install/etc/init.d/xencommons was an empty file. I didn't analyse
>> which patch it was, but I guessed at "move module list into a generic
>> place" and reverting to the patch before that worked, so I've pushed
>> just those, specifically:
>>
>> 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
>> 1846031 oxenstored: also fail if only 1 socket was given by systemd
>> bdc74c9 cxenstored: also fail if only 1 socket was given by systemd
>>
>> I'm a little concerned by the recent lack of comments from systemd folks
>> on the final patch, but there didn't seem much benefit in waiting any
>> longer. Presumably any issues will get shaken down as people test etc.
>>
>> Thanks!
>>
>> Ian.
> 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
>
> has caused quite a lot of collateral damage on my dev tree.  Cheif
> amongst the problems is:
>
> andrewcoop@andrewcoop:/local/xen.git/tools$ make clean
> /local/xen.git/tools/../tools/Rules.mk:8:
> /local/xen.git/tools/../config/Paths.mk: No such file or directory
> make: *** No rule to make target
> `/local/xen.git/tools/../config/Paths.mk'.  Stop.
>
> Running ./configure (without any arguments) does not generate Paths.mk
> from Paths.mk.in, which means that I still cant `make clean`
>
> ~Andrew

andrewcoop@andrewcoop:/local/xen.git/tools$ git diff
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 0aa1e6b..5bac700 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -5,7 +5,7 @@ all:
 
 -include $(XEN_ROOT)/config/Tools.mk
 include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/config/Paths.mk
+-include $(XEN_ROOT)/config/Paths.mk
 
 export _INSTALL := $(INSTALL)
 INSTALL = $(XEN_ROOT)/tools/cross-install

Allows `make clean` to work correctly, but I still can't convince
./configure to create Paths.mk

~Andrew

Re: [PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

On Mon, Jul 28, 2014 at 05:57:56PM +0100, Andrew Cooper wrote:
> On 28/07/14 17:52, Andrew Cooper wrote:
> > On 28/07/14 13:46, Ian Campbell wrote:
> >> On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> >>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>>
> >>> Here's my v8 series. Quite a bit of patches are alreayd merged
> >>> on the xen origin/staging branch, this addresses the last feedback
> >>> from the v7 series and is rebased. It contains two fixes spotted
> >>> as possible issues by Ian Campbell.
> >>>
> >>> I think this is it, after about 2 months of spinning patches. Phew.
> >> I was about to ack and apply the lot when I noticed that
> >> dist/install/etc/init.d/xencommons was an empty file. I didn't analyse
> >> which patch it was, but I guessed at "move module list into a generic
> >> place" and reverting to the patch before that worked, so I've pushed
> >> just those, specifically:
> >>
> >> 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
> >> 1846031 oxenstored: also fail if only 1 socket was given by systemd
> >> bdc74c9 cxenstored: also fail if only 1 socket was given by systemd
> >>
> >> I'm a little concerned by the recent lack of comments from systemd folks
> >> on the final patch, but there didn't seem much benefit in waiting any
> >> longer. Presumably any issues will get shaken down as people test etc.
> >>
> >> Thanks!
> >>
> >> Ian.
> > 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
> >
> > has caused quite a lot of collateral damage on my dev tree.  Cheif
> > amongst the problems is:
> >
> > andrewcoop@andrewcoop:/local/xen.git/tools$ make clean
> > /local/xen.git/tools/../tools/Rules.mk:8:
> > /local/xen.git/tools/../config/Paths.mk: No such file or directory
> > make: *** No rule to make target
> > `/local/xen.git/tools/../config/Paths.mk'.  Stop.
> >
> > Running ./configure (without any arguments) does not generate Paths.mk
> > from Paths.mk.in, which means that I still cant `make clean`
> >
> > ~Andrew
> 
> andrewcoop@andrewcoop:/local/xen.git/tools$ git diff
> diff --git a/tools/Rules.mk b/tools/Rules.mk
> index 0aa1e6b..5bac700 100644
> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -5,7 +5,7 @@ all:
>  
>  -include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/Config.mk
> -include $(XEN_ROOT)/config/Paths.mk
> +-include $(XEN_ROOT)/config/Paths.mk
>  
>  export _INSTALL := $(INSTALL)
>  INSTALL = $(XEN_ROOT)/tools/cross-install
> 
> Allows `make clean` to work correctly, but I still can't convince
> ./configure to create Paths.mk

Did you run autogen.sh?

  Luis

Re: [PATCH v8 0/6] xen: systemd support

[Luis R. Rodriguez]

On Mon, Jul 28, 2014 at 07:00:15PM +0200, Luis R. Rodriguez wrote:
> On Mon, Jul 28, 2014 at 05:57:56PM +0100, Andrew Cooper wrote:
> > On 28/07/14 17:52, Andrew Cooper wrote:
> > > On 28/07/14 13:46, Ian Campbell wrote:
> > >> On Fri, 2014-07-25 at 19:14 -0700, Luis R. Rodriguez wrote:
> > >>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > >>>
> > >>> Here's my v8 series. Quite a bit of patches are alreayd merged
> > >>> on the xen origin/staging branch, this addresses the last feedback
> > >>> from the v7 series and is rebased. It contains two fixes spotted
> > >>> as possible issues by Ian Campbell.
> > >>>
> > >>> I think this is it, after about 2 months of spinning patches. Phew.
> > >> I was about to ack and apply the lot when I noticed that
> > >> dist/install/etc/init.d/xencommons was an empty file. I didn't analyse
> > >> which patch it was, but I guessed at "move module list into a generic
> > >> place" and reverting to the patch before that worked, so I've pushed
> > >> just those, specifically:
> > >>
> > >> 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
> > >> 1846031 oxenstored: also fail if only 1 socket was given by systemd
> > >> bdc74c9 cxenstored: also fail if only 1 socket was given by systemd
> > >>
> > >> I'm a little concerned by the recent lack of comments from systemd folks
> > >> on the final patch, but there didn't seem much benefit in waiting any
> > >> longer. Presumably any issues will get shaken down as people test etc.
> > >>
> > >> Thanks!
> > >>
> > >> Ian.
> > > 54f2891 autoconf: xen: move standard path variables to config/Paths.mk
> > >
> > > has caused quite a lot of collateral damage on my dev tree.  Cheif
> > > amongst the problems is:
> > >
> > > andrewcoop@andrewcoop:/local/xen.git/tools$ make clean
> > > /local/xen.git/tools/../tools/Rules.mk:8:
> > > /local/xen.git/tools/../config/Paths.mk: No such file or directory
> > > make: *** No rule to make target
> > > `/local/xen.git/tools/../config/Paths.mk'.  Stop.
> > >
> > > Running ./configure (without any arguments) does not generate Paths.mk
> > > from Paths.mk.in, which means that I still cant `make clean`
> > >
> > > ~Andrew
> > 
> > andrewcoop@andrewcoop:/local/xen.git/tools$ git diff
> > diff --git a/tools/Rules.mk b/tools/Rules.mk
> > index 0aa1e6b..5bac700 100644
> > --- a/tools/Rules.mk
> > +++ b/tools/Rules.mk
> > @@ -5,7 +5,7 @@ all:
> >  
> >  -include $(XEN_ROOT)/config/Tools.mk
> >  include $(XEN_ROOT)/Config.mk
> > -include $(XEN_ROOT)/config/Paths.mk
> > +-include $(XEN_ROOT)/config/Paths.mk
> >  
> >  export _INSTALL := $(INSTALL)
> >  INSTALL = $(XEN_ROOT)/tools/cross-install
> > 
> > Allows `make clean` to work correctly, but I still can't convince
> > ./configure to create Paths.mk
> 
> Did you run autogen.sh?

Actually you should not need to, odd.

mcgrof@ergon ~/devel/xen (git::staging)$ rm -f config/Paths.mk
mcgrof@ergon ~/devel/xen (git::staging)$ ./configure | grep Paths
config.status: creating config/Paths.mk

What do you see?

 Luis

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Mon, 2014-07-28 at 20:33 +0200, Luis R. Rodriguez wrote:
> > Did you run autogen.sh?
> 
> Actually you should not need to, odd.

Indeed, I did this on commit.

> mcgrof@ergon ~/devel/xen (git::staging)$ rm -f config/Paths.mk
> mcgrof@ergon ~/devel/xen (git::staging)$ ./configure | grep Paths
> config.status: creating config/Paths.mk
> 
> What do you see?

Perhaps Andrew is running "cd tools ; ./configure"?

In http://lists.xen.org/archives/html/xen-devel/2014-07/msg03156.html I
posited that nobody would be doing that (even going so far to doubt that
it worked) but if Andrew is doing it then clearly I was wrong and we
will need to rethink the approach.

If we need to support direct invocation of "sub" configure then the only
approach which comes to my mind is to generate per-subsystem Paths.mk,
e.g. in each of the sub-configures do:
        AC_CONFIG_FILES("../config/Tools-Paths.mk:../config/Paths.mk.in")
along with the other stuff[0] and adjusting the Makefile to use it,
substituting Tools as needed for other subsystems of course.

I think you will also need to -include rather than include so that make
clean et al work on an unconfigured tree. There is existing logic in the
all the (I think) right places to deal with non-clean targets needing
configure to have been run.

BTW, I noticed the opposite problem to Andrew, which is that Paths.mk is
not removed by "make clean".

Ian.

[0]
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Configuration-Files.html says that the : syntax lets you override the input.

Re: [PATCH v8 0/6] xen: systemd support

[Andrew Cooper]

On 29/07/14 09:54, Ian Campbell wrote:
> On Mon, 2014-07-28 at 20:33 +0200, Luis R. Rodriguez wrote:
>>> Did you run autogen.sh?
>> Actually you should not need to, odd.
> Indeed, I did this on commit.
>
>> mcgrof@ergon ~/devel/xen (git::staging)$ rm -f config/Paths.mk
>> mcgrof@ergon ~/devel/xen (git::staging)$ ./configure | grep Paths
>> config.status: creating config/Paths.mk
>>
>> What do you see?
> Perhaps Andrew is running "cd tools ; ./configure"?
>
> In http://lists.xen.org/archives/html/xen-devel/2014-07/msg03156.html I
> posited that nobody would be doing that (even going so far to doubt that
> it worked) but if Andrew is doing it then clearly I was wrong and we
> will need to rethink the approach.

Oh - indeed I am; It certainly did use to work.  At some point in the
past, the outer ./configure was a small shell script which cd'd into
tools and ran ./configure, and I got into the habit of only ever running
./configure from the tools subdir.

>
> If we need to support direct invocation of "sub" configure then the only
> approach which comes to my mind is to generate per-subsystem Paths.mk,
> e.g. in each of the sub-configures do:
>         AC_CONFIG_FILES("../config/Tools-Paths.mk:../config/Paths.mk.in")
> along with the other stuff[0] and adjusting the Makefile to use it,
> substituting Tools as needed for other subsystems of course.

Hmm - I have mixed opinions about this.  On the one hand, it would be
nice for sub configures to work, but splitting Paths.mk like this seems
like a recipe for subtle issues.  Would it be possible for a sub
configure to detect its dependencies and request that the outer
./configure gets run?

~Andrew

>
> I think you will also need to -include rather than include so that make
> clean et al work on an unconfigured tree. There is existing logic in the
> all the (I think) right places to deal with non-clean targets needing
> configure to have been run.
>
> BTW, I noticed the opposite problem to Andrew, which is that Paths.mk is
> not removed by "make clean".
>
> Ian.
>
> [0]
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Configuration-Files.html says that the : syntax lets you override the input.
>

Re: [PATCH v8 0/6] xen: systemd support

[Ian Campbell]

On Tue, 2014-07-29 at 10:33 +0100, Andrew Cooper wrote:
> On 29/07/14 09:54, Ian Campbell wrote:
> > On Mon, 2014-07-28 at 20:33 +0200, Luis R. Rodriguez wrote:
> >>> Did you run autogen.sh?
> >> Actually you should not need to, odd.
> > Indeed, I did this on commit.
> >
> >> mcgrof@ergon ~/devel/xen (git::staging)$ rm -f config/Paths.mk
> >> mcgrof@ergon ~/devel/xen (git::staging)$ ./configure | grep Paths
> >> config.status: creating config/Paths.mk
> >>
> >> What do you see?
> > Perhaps Andrew is running "cd tools ; ./configure"?
> >
> > In http://lists.xen.org/archives/html/xen-devel/2014-07/msg03156.html I
> > posited that nobody would be doing that (even going so far to doubt that
> > it worked) but if Andrew is doing it then clearly I was wrong and we
> > will need to rethink the approach.
> 
> Oh - indeed I am; It certainly did use to work.  At some point in the
> past, the outer ./configure was a small shell script which cd'd into
> tools and ran ./configure, and I got into the habit of only ever running
> ./configure from the tools subdir.

I think given that someone in the world is actually doing this in real
life we should continue to support it (i.e. I was wrong to decide
otherwise before).

> > If we need to support direct invocation of "sub" configure then the only
> > approach which comes to my mind is to generate per-subsystem Paths.mk,
> > e.g. in each of the sub-configures do:
> >         AC_CONFIG_FILES("../config/Tools-Paths.mk:../config/Paths.mk.in")
> > along with the other stuff[0] and adjusting the Makefile to use it,
> > substituting Tools as needed for other subsystems of course.
> 
> Hmm - I have mixed opinions about this.  On the one hand, it would be
> nice for sub configures to work, but splitting Paths.mk like this seems
> like a recipe for subtle issues.

Note that the proposal would have the same Paths.mk.in expanded by the
same m4 macro for every subsystem, so the result should be the same for
everyone, just in an individual file.

People who run configure with different arguments in different subtrees
are no more broken than they were before I think? Are there any other
potential subtle issues?

>   Would it be possible for a sub
> configure to detect its dependencies and request that the outer
> ./configure gets run?

I think as it stands today (i.e. with Luis' patch) they would all need
it, since e.g. $PREFIX comes from here now.

Ian.

Re: [PATCH v8 0/6] xen: systemd support

[Andrew Cooper]

On 29/07/14 10:49, Ian Campbell wrote:
> On Tue, 2014-07-29 at 10:33 +0100, Andrew Cooper wrote:
>> On 29/07/14 09:54, Ian Campbell wrote:
>>> On Mon, 2014-07-28 at 20:33 +0200, Luis R. Rodriguez wrote:
>>>>> Did you run autogen.sh?
>>>> Actually you should not need to, odd.
>>> Indeed, I did this on commit.
>>>
>>>> mcgrof@ergon ~/devel/xen (git::staging)$ rm -f config/Paths.mk
>>>> mcgrof@ergon ~/devel/xen (git::staging)$ ./configure | grep Paths
>>>> config.status: creating config/Paths.mk
>>>>
>>>> What do you see?
>>> Perhaps Andrew is running "cd tools ; ./configure"?
>>>
>>> In http://lists.xen.org/archives/html/xen-devel/2014-07/msg03156.html I
>>> posited that nobody would be doing that (even going so far to doubt that
>>> it worked) but if Andrew is doing it then clearly I was wrong and we
>>> will need to rethink the approach.
>> Oh - indeed I am; It certainly did use to work.  At some point in the
>> past, the outer ./configure was a small shell script which cd'd into
>> tools and ran ./configure, and I got into the habit of only ever running
>> ./configure from the tools subdir.
> I think given that someone in the world is actually doing this in real
> life we should continue to support it (i.e. I was wrong to decide
> otherwise before).
>
>>> If we need to support direct invocation of "sub" configure then the only
>>> approach which comes to my mind is to generate per-subsystem Paths.mk,
>>> e.g. in each of the sub-configures do:
>>>         AC_CONFIG_FILES("../config/Tools-Paths.mk:../config/Paths.mk.in")
>>> along with the other stuff[0] and adjusting the Makefile to use it,
>>> substituting Tools as needed for other subsystems of course.
>> Hmm - I have mixed opinions about this.  On the one hand, it would be
>> nice for sub configures to work, but splitting Paths.mk like this seems
>> like a recipe for subtle issues.
> Note that the proposal would have the same Paths.mk.in expanded by the
> same m4 macro for every subsystem, so the result should be the same for
> everyone, just in an individual file.
>
> People who run configure with different arguments in different subtrees
> are no more broken than they were before I think? Are there any other
> potential subtle issues?
>
>>   Would it be possible for a sub
>> configure to detect its dependencies and request that the outer
>> ./configure gets run?
> I think as it stands today (i.e. with Luis' patch) they would all need
> it, since e.g. $PREFIX comes from here now.
>
> Ian.
>

In which case the best solution is probably to cause the sub configures
to fail if they are not invoked from the top configure.  This avoids the
repeated expansion of Paths.mk and at least makes it clear where
explicit dependences exist.

~Andrew