Re: [Xen-devel] [PATCH v6 13/13] systemd: add xen systemd service and module files

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-06-12 at 18:18 -0700, Luis R. Rodriguez wrote:

> As for integration with xen, we house keep all the systemd files
> under a new directory tools/hotplug/Linux/systemd/ and will be targetted

"targeted".

> by default when building on Linux systems if systemd enabled at
> build time,

This should be predicated on the presence of the systemd libraries, not
on actually running systemd. Think e.g. build chroots. Maybe that's what
you were trying to say anyway?

>  which is only required on the build box, not the user
> system.
> 
> 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.

> @@ -184,6 +185,27 @@ change take effect.
>  [1] http://wiki.xen.org/wiki/XenStoreReference
>  [2] http://wiki.xen.org/wiki/Xenstored
>  
> +Systemd and legacy init 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. Binaries built with systemd supprot

"support" (please run a spell checker)

> +will require systemd libraries to be present on the host system, however
> +systemd initialization will only occur if the system booted with systemd as 
> its
> +init. If systemd was not the init the legacy initialization will be used.
> +Systemd is enabled by default if you have systemd development libraries

This is starting to repeat itself I think (this is the second time this
paragraph talks about the default).

> diff --git a/m4/README.source b/m4/README.source
> index 76f7c5a..8805b8e 100644
> --- a/m4/README.source
> +++ b/m4/README.source
> @@ -26,3 +26,13 @@ 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@xxxxxxxxxxxxxxxx>,
> +its current home project can be found at:
> +
> +https://github.com/mcgrof/funk-systemd
> +
> +There is a plan to upstream this library somehow to systemd.

This last sentence doesn't belong here, we don't much care what upstream
plans to do (whether or not that is you).

> +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()

What is the implication of this? THat we have a workaround for it here
or that we don't support system on systems with pkg-config older than
that?

>  worth also noting is that as of version 208
> +     dnl of systemd pkg-config --cflags currently yields no extra flags yet.

Why is it worth noting that?

> +     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, dnl to work

dnl in the middle of the line suggests a rewrapping snafu.

> +         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.




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