* [PATCH v5 01/14] xenstored: enable usage of config.h on both xenstored and oxenstored
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 02/14] libxenstore.so: add support for systemd Luis R. Rodriguez
` (12 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel; +Cc: Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This will be used later for dynamic configuration paths on C code.
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/ocaml/xenstored/Makefile | 2 ++
tools/xenstore/Makefile | 1 +
2 files changed, 3 insertions(+)
diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
index b18f190..7fa8f53 100644
--- a/tools/ocaml/xenstored/Makefile
+++ b/tools/ocaml/xenstored/Makefile
@@ -2,6 +2,8 @@ XEN_ROOT = $(CURDIR)/../../..
OCAML_TOPLEVEL = $(CURDIR)/..
include $(OCAML_TOPLEVEL)/common.make
+CFLAGS += -I$(XEN_ROOT)/tools/
+
OCAMLINCLUDE += \
-I $(OCAML_TOPLEVEL)/libs/xb \
-I $(OCAML_TOPLEVEL)/libs/mmap \
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index b626104..55ca7a3 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -6,6 +6,7 @@ MINOR = 3
CFLAGS += -Werror
CFLAGS += -I.
+CFLAGS += -I$(XEN_ROOT)/tools/
CFLAGS += $(CFLAGS_libxenctrl)
CLIENTS := xenstore-exists xenstore-list xenstore-read xenstore-rm xenstore-chmod
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 01/14] xenstored: enable usage of config.h on both xenstored and oxenstored Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-21 14:35 ` Ian Campbell
2014-05-20 12:31 ` [PATCH v5 03/14] cxenstored: add support for systemd active sockets Luis R. Rodriguez
` (11 subsequent siblings)
13 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel; +Cc: Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This adds support for systemd into libxenstore.so to enable usage
through cxenstored and oxenstored. The way we provide support for
systemd is to *not* compile systemd with -lsystemd-daemon but instead
to look for libsystemd-daemon.so at run time if the binary was compiled
with support for systemd. Before using systemd though we check if the
system was booted with systemd as the init process by using sd_booted()
and only if this is true will we assume that's the only mechanism
allowed. For systems that do not have systemd present or that have systemd
libraries present but did not boot with systemd the old init unix socket
creation mechanism will be used.
Systems that do not use unix sockets at all will continue to chug on as
they used to skipping all this unix socket actication and relying on the
kernel ring interface, used for exampl when CONFIG_STUBDOM=y which sets
CFLAGS += -DNO_SOCKETS=1 on tools/xenstore/Makefile and also by the
oxenstored --disable_socket run time flag.
This enables Linux distributions to ship and support one binary for both
systemd and non-systemd type of environments.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/xenstore/Makefile | 7 +-
tools/xenstore/xenstore.h | 11 ++
tools/xenstore/xs_systemd.c | 321 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 337 insertions(+), 2 deletions(-)
create mode 100644 tools/xenstore/xs_systemd.c
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 55ca7a3..c361d84 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -9,10 +9,13 @@ CFLAGS += -I.
CFLAGS += -I$(XEN_ROOT)/tools/
CFLAGS += $(CFLAGS_libxenctrl)
+LDFLAGS += -ldl -rdynamic
+
CLIENTS := xenstore-exists xenstore-list xenstore-read xenstore-rm xenstore-chmod
CLIENTS += xenstore-write xenstore-ls xenstore-watch
XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
+XENSTORED_OBJS += xs_systemd.o
XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o xenstored_posix.o
XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_posix.o xenstored_probes.o
@@ -86,10 +89,10 @@ libxenstore.so.$(MAJOR): libxenstore.so.$(MAJOR).$(MINOR)
xs.opic: CFLAGS += -DUSE_PTHREAD
-libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic
+libxenstore.so.$(MAJOR).$(MINOR): xs.opic xs_lib.opic xs_systemd.opic
$(CC) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenstore.so.$(MAJOR) $(SHLIB_LDFLAGS) -o $@ $^ $(SOCKET_LIBS) -lpthread $(APPEND_LDFLAGS)
-libxenstore.a: xs.o xs_lib.o
+libxenstore.a: xs.o xs_lib.o xs_systemd.o
$(AR) rcs $@ $^
.PHONY: clean
diff --git a/tools/xenstore/xenstore.h b/tools/xenstore/xenstore.h
index fdf5e76..11daee4 100644
--- a/tools/xenstore/xenstore.h
+++ b/tools/xenstore/xenstore.h
@@ -49,6 +49,7 @@
#define XS_UNWATCH_FILTER 1UL<<2
struct xs_handle;
+struct xs_sd_ctx;
typedef uint32_t xs_transaction_t;
/* IMPORTANT: For details on xenstore protocol limits, see
@@ -244,6 +245,16 @@ char *xs_debug_command(struct xs_handle *h, const char *cmd,
void *data, unsigned int len);
int xs_suspend_evtchn_port(int domid);
+
+struct xs_sd_ctx *xs_get_sd_ctx(void);
+void xs_free_sd_ctx(struct xs_sd_ctx *ctx);
+
+bool xs_load_sd_required(struct xs_sd_ctx *ctx);
+
+int xs_claim_active_socket(struct xs_sd_ctx *ctx, const char *connect_to);
+
+int xs_sd_notify_ready(struct xs_sd_ctx *ctx);
+
#endif /* XENSTORE_H */
/*
diff --git a/tools/xenstore/xs_systemd.c b/tools/xenstore/xs_systemd.c
new file mode 100644
index 0000000..814e0fc
--- /dev/null
+++ b/tools/xenstore/xs_systemd.c
@@ -0,0 +1,321 @@
+/*
+ xenstored shared interface
+ Copyright (C) 2014 Luis R. Rodriguez <mcgrof@suse.com>
+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ This library 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
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdbool.h>
+#include <stdlib.h>
+#include <assert.h>
+#include <stdbool.h>
+#include <signal.h>
+#include <stdio.h>
+#include <errno.h>
+#include <config.h>
+
+#ifndef NO_SOCKETS
+#if defined(HAVE_SYSTEMD)
+#define XEN_SYSTEMD_ENABLED 1
+#endif
+#endif
+
+#if defined(XEN_SYSTEMD_ENABLED)
+#include <systemd/sd-daemon.h>
+#include <dlfcn.h>
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(ar) (sizeof(ar)/sizeof(ar[0]))
+#endif
+
+/*
+ * Xen supports both systemd and old init style initialization. Xen supports
+ * distributions to ship only one binary to support both systemd and non
+ * systemd systems. We accomplish this by not requiring to link libxenstore.so
+ * with -lsystemd-daemon at compile time but instead having libxenstore.so
+ * ask for libsystemd-daemon.so through run time. Furthremore even if
+ * libsystemd-daemon.so is present it does not mean that a system was booted
+ * with systemd as its init system so we check sd_booted() before assuming
+ * the goal was to require systemd. In a system that did not boot with systemd
+ * as its init daemon but has libsystemd-daemon.so available we'll only require
+ * sd_booted() to verify if init is systemd. Below we explain a bit further how
+ * we accomplish runtime loading of systemd libraries in a portable way.
+ *
+ * dlsym() returns a void pointer, however a void pointer is not required
+ * to even have the same size as an object pointer, and therefore a valid
+ * conversion between type void* and a pointer to a function may not exist
+ * on all platforms. You also may end up with strict-aliasing complaints, so
+ * we use a union. For more details refer to:
+ *
+ * http://en.wikipedia.org/wiki/Dynamic_loading#UNIX_.28POSIX.29
+ *
+ * The strategy taken here is to use a builder for initial assignment
+ * to address issues with different systems with a range of known
+ * expected routines from the library, by usng a macro helper we with
+ * a builder we can enforce only assignment to expected routines from
+ * the library.
+ *
+ * In order to avoid a sloppy union access we upkeep on our own xen
+ * data structure the actual callbacks that we know exist, and leave
+ * the void union trick only for the builder, this requires defining the
+ * expected routines twice, on the builder and our own cached copy of
+ * the symbol dereferences.
+ */
+
+#define XEN_SYSTEMD_FUNCS \
+ int (*sd_booted)(void); \
+ int (*sd_listen_fds)(int unset_environment); \
+ int (*sd_is_fifo)(int fd, const char *path); \
+ int (*sd_is_socket)(int fd, int family, int type, int listening); \
+ int (*sd_is_socket_inet)(int fd, int family, int type, int listening, uint16_t port); \
+ int (*sd_is_socket_unix)(int fd, int type, int listening, const char* path, size_t length); \
+ int (*sd_is_mq)(int fd, const char *path); \
+ int (*sd_notify)(int unset_environment, const char *state); \
+ int (*sd_notifyf)(int unset_environment, const char *format, ...);
+
+union u_sd_funcs {
+ void *f;
+ XEN_SYSTEMD_FUNCS
+};
+
+struct xs_sd_ctx {
+ void *handle;
+ XEN_SYSTEMD_FUNCS
+};
+
+#define xen_load_sd_func(__xs_sd_lib, __libfunc, __builder) do { \
+ __builder.f = NULL; \
+ __builder.f = dlsym(__xs_sd_lib->handle, #__libfunc); \
+ if (!__builder.f) \
+ return false; \
+ __xs_sd_lib->__libfunc = builder.__libfunc; \
+} while (0)
+
+struct xs_sd_ctx *xs_get_sd_ctx(void)
+{
+ struct xs_sd_ctx *ctx;
+ ctx = malloc(sizeof(struct xs_sd_ctx));
+ if (!ctx)
+ return NULL;
+ memset(ctx, 0, sizeof(struct xs_sd_ctx));
+ return ctx;
+}
+
+void xs_free_sd_ctx(struct xs_sd_ctx *ctx)
+{
+ if (!ctx)
+ return;
+ free(ctx);
+}
+
+bool xs_load_sd_required(struct xs_sd_ctx *ctx)
+{
+ union u_sd_funcs builder;
+
+ if (!ctx)
+ return false;
+
+ memset(&builder, 0, sizeof(union u_sd_funcs));
+
+ ctx->handle = dlopen("libsystemd-daemon.so", RTLD_LAZY);
+ if (!ctx->handle)
+ return false;
+
+ xen_load_sd_func(ctx, sd_booted, builder);
+
+ if (!ctx->sd_booted())
+ return false;
+
+ xen_load_sd_func(ctx, sd_listen_fds, builder);
+ xen_load_sd_func(ctx, sd_is_socket_unix, builder);
+ xen_load_sd_func(ctx, sd_notify, builder);
+ xen_load_sd_func(ctx, sd_notifyf, builder);
+
+ return true;
+}
+
+/* Conforms to what we should send sd_is_socket_unix() but we add mode */
+struct xen_systemd_active_socket {
+ int fd;
+ int type;
+ int listening;
+ const char *path;
+ int mode;
+ size_t length;
+};
+
+/*
+ * We list stdin, stdout and stderr simply for documentation purposes
+ * and to help our array size fit the number of expected sockets we
+ * as sd_listen_fds() will return 5 for example if you set the socket
+ * service with 2 sockets.
+ */
+static const struct xen_systemd_active_socket xenstore_active_sockets[] = {
+ {
+ .fd = SD_LISTEN_FDS_START -3,
+ .type = 0,
+ .listening = 0,
+ .path = "stdin",
+ .mode = 0600,
+ .length = 0,
+ },
+ {
+ .fd = SD_LISTEN_FDS_START - 2,
+ .type = 0,
+ .listening = 0,
+ .path = "stderr",
+ .mode = 0600,
+ .length = 0,
+ },
+ {
+ .fd = SD_LISTEN_FDS_START - 1,
+ .type = 0,
+ .listening = 0,
+ .path = "stderr",
+ .mode = 0600,
+ .length = 0,
+ },
+ {
+ .fd = SD_LISTEN_FDS_START,
+ .type = SOCK_STREAM,
+ .listening = -1,
+ .path = "/var/run/xenstored/socket",
+ .mode = 0600,
+ .length = 0,
+ },
+ {
+ .fd = SD_LISTEN_FDS_START + 1,
+ .type = SOCK_STREAM,
+ .listening = -1,
+ .path = "/var/run/xenstored/socket_ro",
+ .mode = 0660,
+ .length = 0,
+ },
+};
+
+static const struct xen_systemd_active_socket *get_xen_active_socket(const char *connect_to)
+{
+ unsigned int i;
+
+ for (i=0; i<ARRAY_SIZE(xenstore_active_sockets); i++) {
+ if (!strcmp(connect_to, xenstore_active_sockets[i].path)) {
+ if (!xenstore_active_sockets[i].type)
+ return NULL;
+ return &xenstore_active_sockets[i];
+ }
+ }
+
+ return NULL;
+}
+
+int xs_claim_active_socket(struct xs_sd_ctx *ctx, const char *connect_to)
+{
+ int n, r;
+ const struct xen_systemd_active_socket *active_socket;
+
+ if (!ctx)
+ return -EINVAL;
+
+ if (!ctx->sd_listen_fds)
+ return -EINVAL;
+
+ if (!ctx->sd_is_socket_unix)
+ return -EINVAL;
+
+ active_socket = get_xen_active_socket(connect_to);
+ if (!active_socket)
+ return -EINVAL;
+
+ n = ctx->sd_listen_fds(0);
+ if (n <= 0) {
+ ctx->sd_notifyf(0, "STATUS=Failed to get any active sockets: %s\n"
+ "ERRNO=%i",
+ strerror(errno),
+ errno);
+ return -errno;
+ } else if (n >= (ARRAY_SIZE(xenstore_active_sockets))) {
+ fprintf(stderr, SD_ERR "Expected %d fds but given %d\n",
+ (int) ARRAY_SIZE(xenstore_active_sockets)-1,
+ n);
+ ctx->sd_notifyf(0, "STATUS=Mismatch on number (%d): %s\n"
+ "ERRNO=%d",
+ (int) ARRAY_SIZE(xenstore_active_sockets),
+ strerror(EBADR),
+ EBADR);
+ return -EBADR;
+ }
+
+ r = ctx->sd_is_socket_unix(active_socket->fd,
+ active_socket->type,
+ active_socket->listening,
+ active_socket->path,
+ active_socket->length);
+ if (r <= 0)
+ return -EBADR;
+
+ r = chmod(active_socket->path, active_socket->mode);
+ if (r != 0)
+ return -errno;
+
+ fprintf(stderr, SD_NOTICE "%s socket claimed\n", active_socket->path);
+
+ return active_socket->fd;
+}
+
+void xs_sd_notify_ready(struct xs_sd_ctx *ctx)
+{
+ if (!ctx)
+ return;
+
+ ctx->sd_notify(1, "READY=1");
+ fprintf(stderr, SD_NOTICE "xenstored is ready\n");
+}
+#else
+
+struct xs_sd_ctx {
+ void *handle;
+};
+
+struct xs_sd_ctx *xs_get_sd_ctx(void)
+{
+ return NULL;
+}
+
+void xs_free_sd_ctx(struct xs_sd_ctx *ctx)
+{
+ return;
+}
+
+int xs_claim_active_socket(struct xs_sd_ctx *ctx, const char *connect_to)
+{
+ return -1;
+}
+
+bool xs_load_sd_required(struct xs_sd_ctx *ctx)
+{
+ return false;
+}
+
+void xs_sd_notify_ready(struct xs_sd_ctx *ctx)
+{
+ return;
+}
+#endif /* XEN_SYSTEMD */
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-20 12:31 ` [PATCH v5 02/14] libxenstore.so: add support for systemd Luis R. Rodriguez
@ 2014-05-21 14:35 ` Ian Campbell
2014-05-21 14:56 ` Ian Campbell
2014-05-21 16:24 ` Luis R. Rodriguez
0 siblings, 2 replies; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 14:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis R. Rodriguez
On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This adds support for systemd into libxenstore.so to enable usage
> through cxenstored and oxenstored. The way we provide support for
> systemd is to *not* compile systemd with -lsystemd-daemon but instead
> to look for libsystemd-daemon.so at run time if the binary was compiled
> with support for systemd.
This is not what either Ian or I intended to suggest. It is perfectly
fine for the binary to be dynamically linked against -lsystemd-daemon in
the normal way (and for the resulting binary packages to depend on the
libsystemd-daemon package etc) if the headers etc are present at compile
time.
What we were after was for the actual use of systemd to be runtime not
compile time. IOW it is fine for xenstored to require the library to be
installed, but not that systemd be the init which is in use.
> Before using systemd though we check if the
> system was booted with systemd as the init process by using sd_booted()
> and only if this is true will we assume that's the only mechanism
> allowed. For systems that do not have systemd present or that have systemd
> libraries present but did not boot with systemd the old init unix socket
> creation mechanism will be used.
>
> Systems that do not use unix sockets at all will continue to chug on as
> they used to skipping all this unix socket actication and relying on the
"activation"
> kernel ring interface, used for exampl when CONFIG_STUBDOM=y which sets
"example"
> diff --git a/tools/xenstore/xs_systemd.c b/tools/xenstore/xs_systemd.c
> new file mode 100644
> index 0000000..814e0fc
> --- /dev/null
> +++ b/tools/xenstore/xs_systemd.c
> +
> +/*
> + * We list stdin, stdout and stderr simply for documentation purposes
> + * and to help our array size fit the number of expected sockets we
> + * as sd_listen_fds() will return 5 for example if you set the socket
> + * service with 2 sockets.
Please can we get rid of this list (which is bad enough in itself but
the three spurious entries are ludicrous) and just
#define SOCKET_RW_INDEX SD_LISTEN_FDS_START
#define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
etc and use those for lookups, as I described in
<1399971222.11314.27.camel@kazak.uk.xensource.com>?
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 14:35 ` Ian Campbell
@ 2014-05-21 14:56 ` Ian Campbell
2014-05-21 16:32 ` Luis R. Rodriguez
2014-05-21 16:24 ` Luis R. Rodriguez
1 sibling, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 14:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis R. Rodriguez
On Wed, 2014-05-21 at 15:35 +0100, Ian Campbell wrote:
> > +
> > +/*
> > + * We list stdin, stdout and stderr simply for documentation purposes
> > + * and to help our array size fit the number of expected sockets we
> > + * as sd_listen_fds() will return 5 for example if you set the socket
> > + * service with 2 sockets.
>
> Please can we get rid of this list (which is bad enough in itself but
> the three spurious entries are ludicrous) and just
> #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> etc and use those for lookups, as I described in
> <1399971222.11314.27.camel@kazak.uk.xensource.com>?
Also I thought that we decided that the mapping from the indexes here to
the functionality need to be documented as well, I'm not seeing that, at
least not based on a skim of the other subject lines in this series.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 14:56 ` Ian Campbell
@ 2014-05-21 16:32 ` Luis R. Rodriguez
2014-05-21 16:48 ` Ian Campbell
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 16:32 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Luis R. Rodriguez
On Wed, May 21, 2014 at 03:56:54PM +0100, Ian Campbell wrote:
> On Wed, 2014-05-21 at 15:35 +0100, Ian Campbell wrote:
>
> > > +
> > > +/*
> > > + * We list stdin, stdout and stderr simply for documentation purposes
> > > + * and to help our array size fit the number of expected sockets we
> > > + * as sd_listen_fds() will return 5 for example if you set the socket
> > > + * service with 2 sockets.
> >
> > Please can we get rid of this list (which is bad enough in itself but
> > the three spurious entries are ludicrous) and just
> > #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> > #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> > etc and use those for lookups, as I described in
> > <1399971222.11314.27.camel@kazak.uk.xensource.com>?
>
> Also I thought that we decided that the mapping from the indexes here to
> the functionality need to be documented as well, I'm not seeing that, at
> least not based on a skim of the other subject lines in this series.
I didn't like the #define approach so wanted to pitch it again under
new usage, I'll be sure to add something once a final approach is
decided.
Please note that another reason for tucking things away under a list
and library was to *eventually* remove the different definitions of
these socket's paths. That code is already split up but can be brought
together under libxenstore and for the systemd case the list can be
used to to do an O(1) lookup of the socket path in the list. If we
use just #defines we would just be adding more #defines for other
things other than the file descriptor for systemd, we'd have it also
for mode, and paths. The list therefore seemed more attractive.
Let me know.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 16:32 ` Luis R. Rodriguez
@ 2014-05-21 16:48 ` Ian Campbell
2014-05-21 17:15 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 16:48 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis R. Rodriguez
On Wed, 2014-05-21 at 18:32 +0200, Luis R. Rodriguez wrote:
> On Wed, May 21, 2014 at 03:56:54PM +0100, Ian Campbell wrote:
> > On Wed, 2014-05-21 at 15:35 +0100, Ian Campbell wrote:
> >
> > > > +
> > > > +/*
> > > > + * We list stdin, stdout and stderr simply for documentation purposes
> > > > + * and to help our array size fit the number of expected sockets we
> > > > + * as sd_listen_fds() will return 5 for example if you set the socket
> > > > + * service with 2 sockets.
> > >
> > > Please can we get rid of this list (which is bad enough in itself but
> > > the three spurious entries are ludicrous) and just
> > > #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> > > #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> > > etc and use those for lookups, as I described in
> > > <1399971222.11314.27.camel@kazak.uk.xensource.com>?
> >
> > Also I thought that we decided that the mapping from the indexes here to
> > the functionality need to be documented as well, I'm not seeing that, at
> > least not based on a skim of the other subject lines in this series.
>
> I didn't like the #define approach
The indexes are into the systemd provided environment variable of the
fds which it has produced for us. It *must* be documented what
xenstored's expectations are wrt what is in that array. Non optional and
completely orthogonal to the use of #defines or anything else.
> so wanted to pitch it again under
> new usage, I'll be sure to add something once a final approach is
> decided.
>
> Please note that another reason for tucking things away under a list
> and library was to *eventually* remove the different definitions of
> these socket's paths.
> That code is already split up but can be brought
> together under libxenstore and for the systemd case the list can be
> used to to do an O(1) lookup of the socket path in the list. If we
> use just #defines we would just be adding more #defines for other
> things other than the file descriptor for systemd, we'd have it also
> for mode, and paths. The list therefore seemed more attractive.
I'm afraid non of this makes any sense to me.
If this mad list of paths and indexes scheme is The Systemd Way then
please provide references. Otherwise:
systemd case:
int get_handle(int index)
{
return sd_listen_fds(index);
}
no extra uses of the path or need for #defines for modes or anything
like that.
non-systemd case:
switch(index)
case SOCKET_WR_INDEX:
open /var/run/xensotred/socket by whatever means.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 16:48 ` Ian Campbell
@ 2014-05-21 17:15 ` Luis R. Rodriguez
2014-05-22 9:36 ` Ian Campbell
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 17:15 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Luis R. Rodriguez
On Wed, May 21, 2014 at 05:48:37PM +0100, Ian Campbell wrote:
> On Wed, 2014-05-21 at 18:32 +0200, Luis R. Rodriguez wrote:
> > On Wed, May 21, 2014 at 03:56:54PM +0100, Ian Campbell wrote:
> > > On Wed, 2014-05-21 at 15:35 +0100, Ian Campbell wrote:
> > >
> > > > > +
> > > > > +/*
> > > > > + * We list stdin, stdout and stderr simply for documentation purposes
> > > > > + * and to help our array size fit the number of expected sockets we
> > > > > + * as sd_listen_fds() will return 5 for example if you set the socket
> > > > > + * service with 2 sockets.
> > > >
> > > > Please can we get rid of this list (which is bad enough in itself but
> > > > the three spurious entries are ludicrous) and just
> > > > #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> > > > #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> > > > etc and use those for lookups, as I described in
> > > > <1399971222.11314.27.camel@kazak.uk.xensource.com>?
> > >
> > > Also I thought that we decided that the mapping from the indexes here to
> > > the functionality need to be documented as well, I'm not seeing that, at
> > > least not based on a skim of the other subject lines in this series.
> >
> > I didn't like the #define approach
>
> The indexes are into the systemd provided environment variable of the
> fds which it has produced for us. It *must* be documented what
> xenstored's expectations are wrt what is in that array. Non optional and
> completely orthogonal to the use of #defines or anything else.
Sure.
> > so wanted to pitch it again under
> > new usage, I'll be sure to add something once a final approach is
> > decided.
> >
> > Please note that another reason for tucking things away under a list
> > and library was to *eventually* remove the different definitions of
> > these socket's paths.
>
> > That code is already split up but can be brought
> > together under libxenstore and for the systemd case the list can be
> > used to to do an O(1) lookup of the socket path in the list. If we
> > use just #defines we would just be adding more #defines for other
> > things other than the file descriptor for systemd, we'd have it also
> > for mode, and paths. The list therefore seemed more attractive.
>
> I'm afraid non of this makes any sense to me.
>
> If this mad list of paths and indexes scheme is The Systemd Way then
> please provide references. Otherwise:
>
> systemd case:
>
> int get_handle(int index)
> {
> return sd_listen_fds(index);
That's not the way to use sd_listen_fds(). More on this below.
> }
>
> no extra uses of the path or need for #defines for modes or anything
> like that.
>
> non-systemd case:
> switch(index)
> case SOCKET_WR_INDEX:
> open /var/run/xensotred/socket by whatever means.
The struct I defined is not something part of systemd, in fact there
are not many example codes out there that use multiple sockets but the
approach to use multiple sockets is to actually only call sd_listen_fds()
once. That returns the list of sockets that systemd was configured through
service units that process should have, systemd would have activated them
for us, we just then carry them over. We do sanity checks with the number
returned, so if we expected systemd to have set up 2 sockets for us we
should check for that number and then *additionally* systemd *does*
recommend that we validate the type of socket is what we expected and
hence the usage of sd_is_socket_unix(). The arguments for
sd_is_socket_unix() is what I set up in a struct mapped by the path.
This is what xs_claim_active_socket() ends up doing for us.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 17:15 ` Luis R. Rodriguez
@ 2014-05-22 9:36 ` Ian Campbell
2014-05-22 9:59 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-22 9:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis R. Rodriguez
On Wed, 2014-05-21 at 19:15 +0200, Luis R. Rodriguez wrote:
> On Wed, May 21, 2014 at 05:48:37PM +0100, Ian Campbell wrote:
> > On Wed, 2014-05-21 at 18:32 +0200, Luis R. Rodriguez wrote:
> > > On Wed, May 21, 2014 at 03:56:54PM +0100, Ian Campbell wrote:
> > > > On Wed, 2014-05-21 at 15:35 +0100, Ian Campbell wrote:
> > > >
> > > > > > +
> > > > > > +/*
> > > > > > + * We list stdin, stdout and stderr simply for documentation purposes
> > > > > > + * and to help our array size fit the number of expected sockets we
> > > > > > + * as sd_listen_fds() will return 5 for example if you set the socket
> > > > > > + * service with 2 sockets.
> > > > >
> > > > > Please can we get rid of this list (which is bad enough in itself but
> > > > > the three spurious entries are ludicrous) and just
> > > > > #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> > > > > #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> > > > > etc and use those for lookups, as I described in
> > > > > <1399971222.11314.27.camel@kazak.uk.xensource.com>?
> > > >
> > > > Also I thought that we decided that the mapping from the indexes here to
> > > > the functionality need to be documented as well, I'm not seeing that, at
> > > > least not based on a skim of the other subject lines in this series.
> > >
> > > I didn't like the #define approach
> >
> > The indexes are into the systemd provided environment variable of the
> > fds which it has produced for us. It *must* be documented what
> > xenstored's expectations are wrt what is in that array. Non optional and
> > completely orthogonal to the use of #defines or anything else.
>
> Sure.
>
> > > so wanted to pitch it again under
> > > new usage, I'll be sure to add something once a final approach is
> > > decided.
> > >
> > > Please note that another reason for tucking things away under a list
> > > and library was to *eventually* remove the different definitions of
> > > these socket's paths.
> >
> > > That code is already split up but can be brought
> > > together under libxenstore and for the systemd case the list can be
> > > used to to do an O(1) lookup of the socket path in the list. If we
> > > use just #defines we would just be adding more #defines for other
> > > things other than the file descriptor for systemd, we'd have it also
> > > for mode, and paths. The list therefore seemed more attractive.
> >
> > I'm afraid non of this makes any sense to me.
> >
> > If this mad list of paths and indexes scheme is The Systemd Way then
> > please provide references. Otherwise:
> >
> > systemd case:
> >
> > int get_handle(int index)
> > {
> > return sd_listen_fds(index);
>
> That's not the way to use sd_listen_fds(). More on this below.
>
> > }
> >
> > no extra uses of the path or need for #defines for modes or anything
> > like that.
> >
> > non-systemd case:
> > switch(index)
> > case SOCKET_WR_INDEX:
> > open /var/run/xensotred/socket by whatever means.
>
> The struct I defined is not something part of systemd, in fact there
> are not many example codes out there that use multiple sockets but the
> approach to use multiple sockets is to actually only call sd_listen_fds()
> once.
OK, so fds = sd_listen_fds() once then return fds[index] above instead
(modulo the checks you want to do).
> That returns the list of sockets that systemd was configured through
> service units that process should have, systemd would have activated them
> for us, we just then carry them over. We do sanity checks with the number
> returned, so if we expected systemd to have set up 2 sockets for us we
> should check for that number and then *additionally* systemd *does*
> recommend that we validate the type of socket is what we expected and
> hence the usage of sd_is_socket_unix(). The arguments for
> sd_is_socket_unix() is what I set up in a struct mapped by the path.
> This is what xs_claim_active_socket() ends up doing for us.
Passing a NULL path to sd_is_socket_unix() is valid though, which means
you don't need the path in two places (the unit file and here). The
length and listening should both always be 0, so you don't need those
either. The mode for chmod seems strange to me, does systemd not let you
configure that? In any case a table lookup for that one thing seems like
overkill to me, you could put it in the switch for instance.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-22 9:36 ` Ian Campbell
@ 2014-05-22 9:59 ` Luis R. Rodriguez
0 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-22 9:59 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Luis R. Rodriguez
On Thu, May 22, 2014 at 10:36:08AM +0100, Ian Campbell wrote:
> On Wed, 2014-05-21 at 19:15 +0200, Luis R. Rodriguez wrote:
> > The struct I defined is not something part of systemd, in fact there
> > are not many example codes out there that use multiple sockets but the
> > approach to use multiple sockets is to actually only call sd_listen_fds()
> > once.
>
> OK, so fds = sd_listen_fds() once then return fds[index] above instead
> (modulo the checks you want to do).
Now we're talking. Yes. Brilliant.
> > for us, we just then carry them over. We do sanity checks with the number
> > returned, so if we expected systemd to have set up 2 sockets for us we
> > should check for that number and then *additionally* systemd *does*
> > recommend that we validate the type of socket is what we expected and
> > hence the usage of sd_is_socket_unix(). The arguments for
> > sd_is_socket_unix() is what I set up in a struct mapped by the path.
> > This is what xs_claim_active_socket() ends up doing for us.
>
> Passing a NULL path to sd_is_socket_unix() is valid though, which means
> you don't need the path in two places (the unit file and here). The
> length and listening should both always be 0,
Actually in practice it seems listening is 1 as I guess systemd listens on
the socket before hand. I tested this with const data and it doesn't
matter what socket I try to activate, only 1 yields correct and expected
results. The fields that have 0 -- I am not sure if we can ignore those,
in kernel land you can as the stack sets data to 0, but in userspace
I'm afraid that is not true unless you memset 0.
> so you don't need those
> either. The mode for chmod seems strange to me, does systemd not let you
> configure that?
Only one mode is allowed, I tried all combinations and no, it only
allows one single mode for all, which means we have to set a single
restrictive mode first and then once the sockets are claimed we do
what we need and chmod().
> In any case a table lookup for that one thing seems like
> overkill to me, you could put it in the switch for instance.
Whatever works. I think you get what is needed now though.
I actualy don't think a const table is bad, in fact I think
it saves space, makes things cleaner, and clear. I'll do the
switch though.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 14:35 ` Ian Campbell
2014-05-21 14:56 ` Ian Campbell
@ 2014-05-21 16:24 ` Luis R. Rodriguez
2014-05-21 16:39 ` Ian Campbell
1 sibling, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 16:24 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Luis R. Rodriguez
On Wed, May 21, 2014 at 03:35:19PM +0100, Ian Campbell wrote:
> On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > This adds support for systemd into libxenstore.so to enable usage
> > through cxenstored and oxenstored. The way we provide support for
> > systemd is to *not* compile systemd with -lsystemd-daemon but instead
> > to look for libsystemd-daemon.so at run time if the binary was compiled
> > with support for systemd.
>
> This is not what either Ian or I intended to suggest. It is perfectly
> fine for the binary to be dynamically linked against -lsystemd-daemon in
> the normal way (and for the resulting binary packages to depend on the
> libsystemd-daemon package etc) if the headers etc are present at compile
> time.
>
> What we were after was for the actual use of systemd to be runtime not
> compile time. IOW it is fine for xenstored to require the library to be
> installed, but not that systemd be the init which is in use.
In order to work dynamically *and* automatically at run time, that is
to let the binary figure out what is best, the dynamic linker was the
best choice. The reason is that we have to consider a binary that
can run on systems that do not have the systemd libraries present, or
that have them but didn't use sytemd as the init process. This solution
covers all those cases.
> > diff --git a/tools/xenstore/xs_systemd.c b/tools/xenstore/xs_systemd.c
> > new file mode 100644
> > index 0000000..814e0fc
> > --- /dev/null
> > +++ b/tools/xenstore/xs_systemd.c
>
> > +
> > +/*
> > + * We list stdin, stdout and stderr simply for documentation purposes
> > + * and to help our array size fit the number of expected sockets we
> > + * as sd_listen_fds() will return 5 for example if you set the socket
> > + * service with 2 sockets.
>
> Please can we get rid of this list (which is bad enough in itself but
> the three spurious entries are ludicrous)
>
> and just
> #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> etc and use those for lookups, as I described in
> <1399971222.11314.27.camel@kazak.uk.xensource.com>?
Did you see the mode? Its an example of how different preferences can
be tucked away under it, but we can always statically peg associations.
The purpose of the list was also to allow a switch on the type to
alternate on sd_is_socket_*() calls but of course if we're not growing
the xenstore implementation this means we only have to deal with one
type and can use that statically.
Up to you, just consider the above and let me know.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 16:24 ` Luis R. Rodriguez
@ 2014-05-21 16:39 ` Ian Campbell
2014-05-21 17:29 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 16:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis R. Rodriguez
On Wed, 2014-05-21 at 18:24 +0200, Luis R. Rodriguez wrote:
> On Wed, May 21, 2014 at 03:35:19PM +0100, Ian Campbell wrote:
> > On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > >
> > > This adds support for systemd into libxenstore.so to enable usage
> > > through cxenstored and oxenstored. The way we provide support for
> > > systemd is to *not* compile systemd with -lsystemd-daemon but instead
> > > to look for libsystemd-daemon.so at run time if the binary was compiled
> > > with support for systemd.
> >
> > This is not what either Ian or I intended to suggest. It is perfectly
> > fine for the binary to be dynamically linked against -lsystemd-daemon in
> > the normal way (and for the resulting binary packages to depend on the
> > libsystemd-daemon package etc) if the headers etc are present at compile
> > time.
> >
> > What we were after was for the actual use of systemd to be runtime not
> > compile time. IOW it is fine for xenstored to require the library to be
> > installed, but not that systemd be the init which is in use.
>
> In order to work dynamically *and* automatically at run time, that is
> to let the binary figure out what is best, the dynamic linker was the
> best choice. The reason is that we have to consider a binary that
> can run on systems that do not have the systemd libraries present,
This is not a requirement. If the systemd libraries were present at
build time then it is acceptable to require them at runtime even if
systemd is not actually in use. (Of course other than he
"is_systemd_being_used" function nothing in the library really ought to
get called in this case)
> or that have them but didn't use sytemd as the init process.
That case must work but if it required dlopen then something is horribly
broken somewhere.
> This solution
> covers all those cases.
>
> > > diff --git a/tools/xenstore/xs_systemd.c b/tools/xenstore/xs_systemd.c
> > > new file mode 100644
> > > index 0000000..814e0fc
> > > --- /dev/null
> > > +++ b/tools/xenstore/xs_systemd.c
> >
> > > +
> > > +/*
> > > + * We list stdin, stdout and stderr simply for documentation purposes
> > > + * and to help our array size fit the number of expected sockets we
> > > + * as sd_listen_fds() will return 5 for example if you set the socket
> > > + * service with 2 sockets.
> >
> > Please can we get rid of this list (which is bad enough in itself but
> > the three spurious entries are ludicrous)
> >
> > and just
> > #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> > #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> > etc and use those for lookups, as I described in
> > <1399971222.11314.27.camel@kazak.uk.xensource.com>?
>
> Did you see the mode? Its an example of how different preferences can
> be tucked away under it, but we can always statically peg associations.
I have no idea what you are trying to ask/say here...
> The purpose of the list was also to allow a switch on the type to
> alternate on sd_is_socket_*() calls but of course if we're not growing
> the xenstore implementation this means we only have to deal with one
> type and can use that statically.
...or here.
If socket activation is enabled then both of the things we are passed
should be unix domain sockets so I don't understand why you would need
to "alternate" on anything there either. And if a new thing were added
to the list then its index would imply that it was whatever type it must
be, because you'd have written it in the spec.
> Up to you, just consider the above and let me know.
The list should go.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 16:39 ` Ian Campbell
@ 2014-05-21 17:29 ` Luis R. Rodriguez
2014-05-22 9:39 ` Ian Campbell
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 17:29 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Luis R. Rodriguez
On Wed, May 21, 2014 at 05:39:31PM +0100, Ian Campbell wrote:
> On Wed, 2014-05-21 at 18:24 +0200, Luis R. Rodriguez wrote:
> > On Wed, May 21, 2014 at 03:35:19PM +0100, Ian Campbell wrote:
> > > On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > >
> > > > This adds support for systemd into libxenstore.so to enable usage
> > > > through cxenstored and oxenstored. The way we provide support for
> > > > systemd is to *not* compile systemd with -lsystemd-daemon but instead
> > > > to look for libsystemd-daemon.so at run time if the binary was compiled
> > > > with support for systemd.
> > >
> > > This is not what either Ian or I intended to suggest. It is perfectly
> > > fine for the binary to be dynamically linked against -lsystemd-daemon in
> > > the normal way (and for the resulting binary packages to depend on the
> > > libsystemd-daemon package etc) if the headers etc are present at compile
> > > time.
> > >
> > > What we were after was for the actual use of systemd to be runtime not
> > > compile time. IOW it is fine for xenstored to require the library to be
> > > installed, but not that systemd be the init which is in use.
> >
> > In order to work dynamically *and* automatically at run time, that is
> > to let the binary figure out what is best, the dynamic linker was the
> > best choice. The reason is that we have to consider a binary that
> > can run on systems that do not have the systemd libraries present,
>
> This is not a requirement. If the systemd libraries were present at
> build time then it is acceptable to require them at runtime even if
> systemd is not actually in use. (Of course other than he
> "is_systemd_being_used" function nothing in the library really ought to
> get called in this case)
It was not clear that this was not a requirement and hence the use of
dlopen() and dlsym(). Now that that work is done though up to you guys
to decide what you want, this option works now, I've tested it, so
just let me know.
I believe the existing use integration provides the most flexibility.
> > or that have them but didn't use sytemd as the init process.
>
> That case must work but if it required dlopen then something is horribly
> broken somewhere.
If a requirement was not to produce binaries to work on non systemd systems
then yes, otherwise no.
> > This solution
> > covers all those cases.
> >
> > > > diff --git a/tools/xenstore/xs_systemd.c b/tools/xenstore/xs_systemd.c
> > > > new file mode 100644
> > > > index 0000000..814e0fc
> > > > --- /dev/null
> > > > +++ b/tools/xenstore/xs_systemd.c
> > >
> > > > +
> > > > +/*
> > > > + * We list stdin, stdout and stderr simply for documentation purposes
> > > > + * and to help our array size fit the number of expected sockets we
> > > > + * as sd_listen_fds() will return 5 for example if you set the socket
> > > > + * service with 2 sockets.
> > >
> > > Please can we get rid of this list (which is bad enough in itself but
> > > the three spurious entries are ludicrous)
> > >
> > > and just
> > > #define SOCKET_RW_INDEX SD_LISTEN_FDS_START
> > > #define SOCKET_RO_INDEX SDL_LISTEN_FDS_START + 1
> > > etc and use those for lookups, as I described in
> > > <1399971222.11314.27.camel@kazak.uk.xensource.com>?
> >
> > Did you see the mode? Its an example of how different preferences can
> > be tucked away under it, but we can always statically peg associations.
>
> I have no idea what you are trying to ask/say here...
There are seval uses of the structure I defined, one is the making it
easier to call sd_is_socket_unix() with already prepared data, the other
use case is to chmod() the socket on the path given that while systemd
service unit files does support specifying permissions on the sockets
its a wide set permission setting, so changes between permissions must
be handled manually right now. See the use of chmod on xs_claim_active_socket()
Its another example of the use of the structure format I laid out instead
of defines.
> > The purpose of the list was also to allow a switch on the type to
> > alternate on sd_is_socket_*() calls but of course if we're not growing
> > the xenstore implementation this means we only have to deal with one
> > type and can use that statically.
>
> ...or here.
>
> If socket activation is enabled then both of the things we are passed
> should be unix domain sockets
It doesn't matter, systemd documentation recommends for a sanity check
on the type of socket given back to us by systemd, and hance the use
of sd_is_socket_unix().
> so I don't understand why you would need
> to "alternate" on anything there either.
What I mean by alternating on different sd_is_socket_*() calls is if we were to
grow xenstored with different type of sockets and make the code a bit more
dynamic. In such case we'd just throw a switch on the active_socket->type and
call the appropriate sd_is_socket_*().
> And if a new thing were added
> to the list then its index would imply that it was whatever type it must
> be, because you'd have written it in the spec.
Even so you are still recommended to call sd_is_socket_*() for the type of
expected socket. What I did tries to make the code easier to grow and
manage.
> > Up to you, just consider the above and let me know.
>
> The list should go.
OK...
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 02/14] libxenstore.so: add support for systemd
2014-05-21 17:29 ` Luis R. Rodriguez
@ 2014-05-22 9:39 ` Ian Campbell
2014-05-22 10:01 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-22 9:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis R. Rodriguez
On Wed, 2014-05-21 at 19:29 +0200, Luis R. Rodriguez wrote:
> On Wed, May 21, 2014 at 05:39:31PM +0100, Ian Campbell wrote:
> > On Wed, 2014-05-21 at 18:24 +0200, Luis R. Rodriguez wrote:
> > > On Wed, May 21, 2014 at 03:35:19PM +0100, Ian Campbell wrote:
> > > > On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > >
> > > > > This adds support for systemd into libxenstore.so to enable usage
> > > > > through cxenstored and oxenstored. The way we provide support for
> > > > > systemd is to *not* compile systemd with -lsystemd-daemon but instead
> > > > > to look for libsystemd-daemon.so at run time if the binary was compiled
> > > > > with support for systemd.
> > > >
> > > > This is not what either Ian or I intended to suggest. It is perfectly
> > > > fine for the binary to be dynamically linked against -lsystemd-daemon in
> > > > the normal way (and for the resulting binary packages to depend on the
> > > > libsystemd-daemon package etc) if the headers etc are present at compile
> > > > time.
> > > >
> > > > What we were after was for the actual use of systemd to be runtime not
> > > > compile time. IOW it is fine for xenstored to require the library to be
> > > > installed, but not that systemd be the init which is in use.
> > >
> > > In order to work dynamically *and* automatically at run time, that is
> > > to let the binary figure out what is best, the dynamic linker was the
> > > best choice. The reason is that we have to consider a binary that
> > > can run on systems that do not have the systemd libraries present,
> >
> > This is not a requirement. If the systemd libraries were present at
> > build time then it is acceptable to require them at runtime even if
> > systemd is not actually in use. (Of course other than he
> > "is_systemd_being_used" function nothing in the library really ought to
> > get called in this case)
>
> It was not clear that this was not a requirement and hence the use of
> dlopen() and dlsym(). Now that that work is done though up to you guys
> to decide what you want, this option works now, I've tested it, so
> just let me know.
>
> I believe the existing use integration provides the most flexibility.
Please drop dlopen and just link against the libraries.
> > > Did you see the mode? Its an example of how different preferences can
> > > be tucked away under it, but we can always statically peg associations.
> >
> > I have no idea what you are trying to ask/say here...
>
> There are seval uses of the structure I defined, one is the making it
> easier to call sd_is_socket_unix() with already prepared data,
Practically all the arguments to which are static in this case though.
(Once you ignore the totally useless stdio entries)
> the other
> use case is to chmod() the socket on the path given that while systemd
> service unit files does support specifying permissions on the sockets
> its a wide set permission setting, so changes between permissions must
> be handled manually right now. See the use of chmod on xs_claim_active_socket()
I don't think you need a table just to select between 0600 and 0660 out
of a choice of two sockets. At most a switch is needed, even an if would
do for now.
> > so I don't understand why you would need
> > to "alternate" on anything there either.
>
> What I mean by alternating on different sd_is_socket_*() calls is if we were to
> grow xenstored with different type of sockets and make the code a bit more
> dynamic. In such case we'd just throw a switch on the active_socket->type and
> call the appropriate sd_is_socket_*().
No we wouldn't, we'd throw a switch over the index into the lookup
function and handle it there.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v5 03/14] cxenstored: add support for systemd active sockets
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 01/14] xenstored: enable usage of config.h on both xenstored and oxenstored Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 02/14] libxenstore.so: add support for systemd Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 04/14] oxenstored: " Luis R. Rodriguez
` (10 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel; +Cc: Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This adds systemd socket activation support for the C xenstored.
Active sockets enable xenstored to be loaded only if required by a system
onto which Xen is installed on. Socket activation is handled by
systemd, once a port for a service which claims a socket is used
systemd will start the required services for it, on demand. For more
details on socket activation refer to Lennart's socket-activation
post regarding this [0].
Right now this code adds a no-op for this functionality, leaving the
enablement to be done later once systemd is properly hooked into
the build system. The socket activation is ordered in aligment with
the socket activation order passed on to systemd.
[0] http://0pointer.de/blog/projects/socket-activation2.html
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/xenstore/xenstored_core.c | 49 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 47f0722..e456e67 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -40,10 +40,12 @@
#include <signal.h>
#include <assert.h>
#include <setjmp.h>
+#include <config.h>
#include "utils.h"
#include "list.h"
#include "talloc.h"
+#include "xenstore.h"
#include "xenstore_lib.h"
#include "xenstored_core.h"
#include "xenstored_watch.h"
@@ -1706,6 +1708,11 @@ static void init_sockets(int **psock, int **pro_sock)
static int minus_one = -1;
*psock = *pro_sock = &minus_one;
}
+static void xen_claim_active_sockets(struct xs_sd_ctx *ctx, int **psock, int **pro_sock)
+{
+ static int minus_one = -1;
+ *psock = *pro_sock = &minus_one;
+}
#else
static int destroy_fd(void *_fd)
{
@@ -1714,6 +1721,26 @@ static int destroy_fd(void *_fd)
return 0;
}
+static void xen_claim_active_sockets(struct xs_sd_ctx *ctx, int **psock, int **pro_sock)
+{
+ int *sock, *ro_sock;
+ const char *soc_str = xs_daemon_socket();
+ const char *soc_str_ro = xs_daemon_socket_ro();
+
+ *psock = sock = talloc(talloc_autofree_context(), int);
+ *sock = xs_claim_active_socket(ctx, soc_str);
+ if (*sock <= 0)
+ barf_perror("%s", soc_str);
+
+ *pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+ *ro_sock = xs_claim_active_socket(ctx, soc_str_ro);
+ if (*ro_sock <= 0)
+ barf_perror("%s", soc_str_ro);
+
+ talloc_set_destructor(sock, destroy_fd);
+ talloc_set_destructor(ro_sock, destroy_fd);
+}
+
static void init_sockets(int **psock, int **pro_sock)
{
struct sockaddr_un addr;
@@ -1822,8 +1849,10 @@ int main(int argc, char *argv[])
bool dofork = true;
bool outputpid = false;
bool no_domain_init = false;
+ bool sd_booted = false;
const char *pidfile = NULL;
int timeout;
+ struct xs_sd_ctx *ctx;
while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
NULL)) != -1) {
@@ -1884,6 +1913,16 @@ int main(int argc, char *argv[])
if (optind != argc)
barf("%s: No arguments desired", argv[0]);
+ ctx = xs_get_sd_ctx();
+ /* xs_sd_ctx can be NULL and that's OK */
+ if (xs_load_sd_required(ctx)) {
+ sd_booted = true;
+ dofork = false;
+ if (pidfile)
+ barf("%s: PID file not needed on systemd", argv[0]);
+ pidfile = NULL;
+ }
+
reopen_log();
/* make sure xenstored directories exist */
@@ -1905,7 +1944,11 @@ int main(int argc, char *argv[])
/* Don't kill us with SIGPIPE. */
signal(SIGPIPE, SIG_IGN);
- init_sockets(&sock, &ro_sock);
+ if (sd_booted)
+ xen_claim_active_sockets(ctx, &sock, &ro_sock);
+ else
+ init_sockets(&sock, &ro_sock);
+
init_pipe(reopen_log_pipe);
/* Setup the database */
@@ -1936,6 +1979,9 @@ int main(int argc, char *argv[])
/* Tell the kernel we're up and running. */
xenbus_notify_running();
+ if (sd_booted)
+ xs_sd_notify_ready(ctx);
+
/* Main loop. */
for (;;) {
struct connection *conn, *next;
@@ -2047,6 +2093,7 @@ int main(int argc, char *argv[])
initialize_fds(*sock, &sock_pollfd_idx, *ro_sock,
&ro_sock_pollfd_idx, &timeout);
}
+ xs_free_sd_ctx(ctx);
}
/*
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 04/14] oxenstored: add support for systemd active sockets
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (2 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 03/14] cxenstored: add support for systemd active sockets Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 05/14] oxenstored: force FD_CLOEXEC with Unix.set_close_on_exec on LSB init Luis R. Rodriguez
` (9 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: David Scott, Stefano Stabellini, Ian Jackson, Luis R. Rodriguez,
Vincent Hanquez, Ian Campbell
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This adds systemd socket activation support for the Ocaml xenstored.
Ocaml lacks systemd library support so we provide our own C helpers
as is done with other functionality lacking on Ocaml.
Active sockets enables oxenstored to be loaded only if required by a system
onto which Xen is installed on. Socket activation is handled by
systemd, once a port for a service which claims a socket is used
systemd will start the required services for it, on demand. For more
details on socket activation refer to Lennart's socket-activation
post regarding this [0].
An important difference with socket activation is that systemd will set
FD_CLOEXEC for us on the socket before giving it to us, we'll sprinkly
the Unix.set_close_on_exec for LSB init next as a separate commit.
Right now this code adds a no-op for this functionality, leaving the
enablement to be done later once systemd is properly hooked into
the build system. The socket activation is ordered in aligment with
the socket activation order passed on to systemd.
[0] http://0pointer.de/blog/projects/socket-activation2.html
Cc: David Scott <dave.scott@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>
Acked-by: Dave Scott <Dave.Scott@citrix.com>
Acked-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/ocaml/xenstored/Makefile | 11 ++-
tools/ocaml/xenstored/systemd.ml | 17 +++++
tools/ocaml/xenstored/systemd.mli | 24 +++++++
tools/ocaml/xenstored/systemd_stubs.c | 132 ++++++++++++++++++++++++++++++++++
tools/ocaml/xenstored/utils.ml | 20 ++++--
tools/ocaml/xenstored/xenstored.ml | 2 +
6 files changed, 198 insertions(+), 8 deletions(-)
create mode 100644 tools/ocaml/xenstored/systemd.ml
create mode 100644 tools/ocaml/xenstored/systemd.mli
create mode 100644 tools/ocaml/xenstored/systemd_stubs.c
diff --git a/tools/ocaml/xenstored/Makefile b/tools/ocaml/xenstored/Makefile
index 7fa8f53..2f55d8b 100644
--- a/tools/ocaml/xenstored/Makefile
+++ b/tools/ocaml/xenstored/Makefile
@@ -15,6 +15,14 @@ syslog_OBJS = syslog
syslog_C_OBJS = syslog_stubs
OCAML_LIBRARY = syslog
+LDFLAGS += $(LDLIBS_libxenstore)
+CFLAGS += $(CFLAGS_libxenstore)
+
+LIBS += systemd.cma systemd.cmxa
+systemd_OBJS = systemd
+systemd_C_OBJS = systemd_stubs
+OCAML_LIBRARY += systemd
+
OBJS = define \
stdext \
trie \
@@ -36,11 +44,12 @@ OBJS = define \
process \
xenstored
-INTF = symbol.cmi trie.cmi syslog.cmi
+INTF = symbol.cmi trie.cmi syslog.cmi systemd.cmi
XENSTOREDLIBS = \
unix.cmxa \
-ccopt -L -ccopt . syslog.cmxa \
+ -ccopt -L -ccopt . systemd.cmxa \
-ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/mmap $(OCAML_TOPLEVEL)/libs/mmap/xenmmap.cmxa \
-ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/eventchn $(OCAML_TOPLEVEL)/libs/eventchn/xeneventchn.cmxa \
-ccopt -L -ccopt $(OCAML_TOPLEVEL)/libs/xc $(OCAML_TOPLEVEL)/libs/xc/xenctrl.cmxa \
diff --git a/tools/ocaml/xenstored/systemd.ml b/tools/ocaml/xenstored/systemd.ml
new file mode 100644
index 0000000..2d3c8e1
--- /dev/null
+++ b/tools/ocaml/xenstored/systemd.ml
@@ -0,0 +1,17 @@
+(*
+ * 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 Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ *)
+
+external sd_listen_fds: string -> Unix.file_descr = "ocaml_sd_listen_fds"
+external sd_active_socket_required: unit -> bool = "ocaml_sd_active_socket_required"
+external sd_notify_ready: unit -> unit = "ocaml_sd_notify_ready"
diff --git a/tools/ocaml/xenstored/systemd.mli b/tools/ocaml/xenstored/systemd.mli
new file mode 100644
index 0000000..3a42676
--- /dev/null
+++ b/tools/ocaml/xenstored/systemd.mli
@@ -0,0 +1,24 @@
+(*
+ * 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 Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ *)
+
+(** Calls the C library sd_listen_fds() function for us. Although
+ * the library doesn't accept argument we send one over to help
+ * us do sanity checks on the expected sockets *)
+val sd_listen_fds: string -> Unix.file_descr
+
+(** Tells us whether or not systemd support was compiled in *)
+val sd_active_socket_required: unit -> bool
+
+(** Tells systemd we're ready *)
+external sd_notify_ready: unit -> unit = "ocaml_sd_notify_ready"
diff --git a/tools/ocaml/xenstored/systemd_stubs.c b/tools/ocaml/xenstored/systemd_stubs.c
new file mode 100644
index 0000000..76250df
--- /dev/null
+++ b/tools/ocaml/xenstored/systemd_stubs.c
@@ -0,0 +1,132 @@
+/*
+ * 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 Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * 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 Lesser General Public License for more details.
+ */
+
+#include <string.h>
+#include <stdbool.h>
+#include <caml/mlvalues.h>
+#include <caml/memory.h>
+#include <caml/alloc.h>
+#include <caml/custom.h>
+#include <caml/signals.h>
+#include <caml/fail.h>
+#include <config.h>
+#include "xenstore.h"
+
+#if defined(HAVE_SYSTEMD)
+CAMLprim value ocaml_sd_listen_fds(value connect_to)
+{
+ CAMLparam1(connect_to);
+ CAMLlocal1(sock_ret);
+ int sock;
+ struct xs_sd_ctx *ctx;
+
+ sock_ret = Val_int(-1);
+ ctx = xs_get_sd_ctx();
+ if (!ctx)
+ goto out;
+
+ if (!xs_load_sd_required(ctx))
+ goto out;
+
+ sock = xs_claim_active_socket(ctx, (const char *) String_val(connect_to));
+ if (sock <= 0)
+ caml_failwith("ocaml_sd_listen_fds_init() mismatch on socket");
+
+ sock_ret = Val_int(sock);
+
+out:
+ xs_free_sd_ctx(ctx);
+ CAMLreturn(sock_ret);
+}
+
+CAMLprim value ocaml_sd_active_socket_required(value ignore)
+{
+ CAMLparam1(ignore);
+ CAMLlocal1(ret);
+ struct xs_sd_ctx *ctx;
+
+ ret = Val_false;
+
+ /* ctx can be NULL and that's OK */
+ ctx = xs_get_sd_ctx();
+ if (!ctx)
+ goto out;
+
+ if (xs_load_sd_required(ctx))
+ ret = Val_true;
+
+out:
+ xs_free_sd_ctx(ctx);
+ CAMLreturn(ret);
+}
+
+CAMLprim value ocaml_sd_notify_ready(value ignore)
+{
+ CAMLparam1(ignore);
+ CAMLlocal1(ret);
+ struct xs_sd_ctx *ctx;
+
+ ret = Val_int(-1);
+
+ ctx = xs_get_sd_ctx();
+ if (!ctx) {
+ caml_failwith("ocaml_sd_notify_ready() - failed");
+ goto out;
+ }
+
+ if (!xs_load_sd_required(ctx)) {
+ caml_failwith("ocaml_sd_notify_ready() - failed");
+ goto out;
+ }
+
+ ret = Val_int(0);
+
+ xs_sd_notify_ready(ctx);
+out:
+ xs_free_sd_ctx(ctx);
+ CAMLreturn(ret);
+}
+
+#else
+
+CAMLprim value ocaml_sd_listen_fds(value connect_to)
+{
+ CAMLparam1(connect_to);
+ CAMLlocal1(sock_ret);
+
+ sock_ret = Val_int(-1);
+
+ CAMLreturn(sock_ret);
+}
+
+CAMLprim value ocaml_sd_active_socket_required(value ignore)
+{
+ CAMLparam1(ignore);
+ CAMLlocal1(ret);
+
+ ret = Val_false;
+
+ CAMLreturn(ret);
+}
+
+CAMLprim value ocaml_sd_notify_ready(value ignore)
+{
+ CAMLparam1(ignore);
+ CAMLlocal1(ret);
+
+ ret = Val_int(-1);
+
+ CAMLreturn(ret);
+}
+#endif
diff --git a/tools/ocaml/xenstored/utils.ml b/tools/ocaml/xenstored/utils.ml
index 68b70c5..50f05c1 100644
--- a/tools/ocaml/xenstored/utils.ml
+++ b/tools/ocaml/xenstored/utils.ml
@@ -73,14 +73,20 @@ let trim_path path =
let join_by_null ls = String.concat "\000" ls
(* unix utils *)
+let create_regular_unix_socket name =
+ Unixext.unlink_safe name;
+ Unixext.mkdir_rec (Filename.dirname name) 0o700;
+ let sockaddr = Unix.ADDR_UNIX(name) in
+ let sock = Unix.socket Unix.PF_UNIX Unix.SOCK_STREAM 0 in
+ Unix.bind sock sockaddr;
+ Unix.listen sock 1;
+ sock
+
let create_unix_socket name =
- Unixext.unlink_safe name;
- Unixext.mkdir_rec (Filename.dirname name) 0o700;
- let sockaddr = Unix.ADDR_UNIX(name) in
- let sock = Unix.socket Unix.PF_UNIX Unix.SOCK_STREAM 0 in
- Unix.bind sock sockaddr;
- Unix.listen sock 1;
- sock
+ if Systemd.sd_active_socket_required() then
+ Systemd.sd_listen_fds name
+ else
+ create_regular_unix_socket name
let read_file_single_integer filename =
let fd = Unix.openfile filename [ Unix.O_RDONLY ] 0o640 in
diff --git a/tools/ocaml/xenstored/xenstored.ml b/tools/ocaml/xenstored/xenstored.ml
index 438ecb9..b8d18c8 100644
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -383,6 +383,8 @@ let _ =
while not !quit
do
try
+ if Systemd.sd_active_socket_required() then
+ Systemd.sd_notify_ready ();
main_loop ()
with exc ->
error "caught exception %s" (Printexc.to_string exc);
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 05/14] oxenstored: force FD_CLOEXEC with Unix.set_close_on_exec on LSB init
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (3 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 04/14] oxenstored: " Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 06/14] tools/xendomains: make xl the default Luis R. Rodriguez
` (8 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: David Scott, Stefano Stabellini, Vincent Hanquez,
Luis R. Rodriguez, Anil Madhavapeddy, Ian Jackson, Ian Campbell
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Lets match the systemd active socket activation implementation and
ensure that FD_CLOEXEC is set by usin Unix.set_close_on_exec. David
notes oxenstored likely does not exec but there is no harm in being
careful just in case things change in the future.
Cc: David Scott <dave.scott@eu.citrix.com>
Cc: Anil Madhavapeddy <anil@recoil.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/ocaml/xenstored/utils.ml | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/ocaml/xenstored/utils.ml b/tools/ocaml/xenstored/utils.ml
index 50f05c1..b206898 100644
--- a/tools/ocaml/xenstored/utils.ml
+++ b/tools/ocaml/xenstored/utils.ml
@@ -78,6 +78,7 @@ let create_regular_unix_socket name =
Unixext.mkdir_rec (Filename.dirname name) 0o700;
let sockaddr = Unix.ADDR_UNIX(name) in
let sock = Unix.socket Unix.PF_UNIX Unix.SOCK_STREAM 0 in
+ Unix.set_close_on_exec sock;
Unix.bind sock sockaddr;
Unix.listen sock 1;
sock
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 06/14] tools/xendomains: make xl the default
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (4 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 05/14] oxenstored: force FD_CLOEXEC with Unix.set_close_on_exec on LSB init Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-21 15:05 ` Ian Campbell
2014-05-20 12:31 ` [PATCH v5 07/14] tools/xendomains: do space cleanups Luis R. Rodriguez
` (7 subsequent siblings)
13 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, Luis R. Rodriguez,
Jan Rękorajski, Ian Jackson, Jacek Konieczny, M A Young
From: "Luis R. Rodriguez" <mcgrof@suse.com>
If that fails backoff to using xm.
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
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/hotplug/Linux/init.d/xendomains | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index 59f1e3d..6cb1032 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -29,13 +29,13 @@
. /etc/xen/scripts/hotplugpath.sh
-CMD=${SBINDIR}/xm
-HEADCOMP="LinuxGuestRecord"
+CMD=${SBINDIR}/xl
+HEADCOMP="Xen saved domain"
$CMD list &> /dev/null
if test $? -ne 0
then
- CMD=${SBINDIR}/xl
- HEADCOMP="Xen saved domain"
+ CMD=${SBINDIR}/xm
+ HEADCOMP="LinuxGuestRecord"
fi
$CMD list &> /dev/null
--
2.0.0.rc3.18.g00a5b79
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 06/14] tools/xendomains: make xl the default
2014-05-20 12:31 ` [PATCH v5 06/14] tools/xendomains: make xl the default Luis R. Rodriguez
@ 2014-05-21 15:05 ` Ian Campbell
2014-05-21 17:29 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 15:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Stefano Stabellini, Luis R. Rodriguez, Jan Rękorajski,
Ian Jackson, Jacek Konieczny, M A Young, xen-devel
On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> If that fails backoff to using xm.
In <1399476104.13430.145.camel@kazak.uk.xensource.com> on v4 I said
"Please fold it in to one patch to just forget about xm in one go."
where it was a patch removing the now pointless xm fallback. I don't
even see that patch in this series, let alone folded in here.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 06/14] tools/xendomains: make xl the default
2014-05-21 15:05 ` Ian Campbell
@ 2014-05-21 17:29 ` Luis R. Rodriguez
0 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 17:29 UTC (permalink / raw)
To: Ian Campbell
Cc: Stefano Stabellini, Jan Rękorajski, Ian Jackson,
Jacek Konieczny, M A Young, xen-devel, Luis R. Rodriguez
On Wed, May 21, 2014 at 04:05:42PM +0100, Ian Campbell wrote:
> On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > If that fails backoff to using xm.
>
> In <1399476104.13430.145.camel@kazak.uk.xensource.com> on v4 I said
> "Please fold it in to one patch to just forget about xm in one go."
> where it was a patch removing the now pointless xm fallback. I don't
> even see that patch in this series, let alone folded in here.
Dah, sorry, my laptop got hosed and I lost that patch. I merged that now.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v5 07/14] tools/xendomains: do space cleanups
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (5 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 06/14] tools/xendomains: make xl the default Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 08/14] tools/xendomains: move to libexec and use a smaller init helper Luis R. Rodriguez
` (6 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, Luis R. Rodriguez,
Jan Rękorajski, Ian Jackson, Jacek Konieczny, M A Young
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This has no functional changes. This is just to prepare the file
to be moved, so you won't blind your eyes or get git am to complain.
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
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
tools/hotplug/Linux/init.d/xendomains | 62 +++++++++++++++++------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
index 6cb1032..587568d 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -23,7 +23,7 @@
# Default-Start: 2 3 5
# Default-Stop: 0 1 6
# Short-Description: Start/stop secondary xen domains
-# Description: Start / stop domains automatically when domain 0
+# Description: Start / stop domains automatically when domain 0
# boots / shuts down.
### END INIT INFO
@@ -44,7 +44,7 @@ then
exit 0;
fi
-# Correct exit code would probably be 5, but it's enough
+# Correct exit code would probably be 5, but it's enough
# if xend complains if we're not running as privileged domain
if ! [ -e /proc/xen/privcmd ]; then
exit 0
@@ -74,7 +74,7 @@ test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
if test -e /etc/rc.status; then
# SUSE rc script library
. /etc/rc.status
-else
+else
_cmd=$1
declare -a _SMSG
if test "${_cmd}" = "status"; then
@@ -97,7 +97,7 @@ else
fi
}
elif test -e /lib/lsb/init-functions; then
- # LSB
+ # LSB
. /lib/lsb/init-functions
if alias log_success_msg >/dev/null 2>/dev/null; then
echo_rc()
@@ -114,7 +114,7 @@ else
fi
}
fi
- else
+ else
# emulate it
echo_rc()
{
@@ -124,17 +124,17 @@ else
rc_reset() { _RC_RV=0; }
rc_failed()
{
- if test -z "$1"; then
+ if test -z "$1"; then
_RC_RV=1;
- elif test "$1" != "0"; then
- _RC_RV=$1;
- fi
+ elif test "$1" != "0"; then
+ _RC_RV=$1;
+ fi
return ${_RC_RV}
}
rc_check()
{
return rc_failed $?
- }
+ }
rc_status()
{
rc_failed $?
@@ -146,7 +146,7 @@ else
return ${_RC_RV}
}
rc_exit() { exit ${_RC_RV}; }
- rc_active()
+ rc_active()
{
if test -z "$RUNLEVEL"; then read RUNLEVEL REST < <(/sbin/runlevel); fi
if test -e /etc/init.d/S[0-9][0-9]${1}; then return 0; fi
@@ -193,13 +193,13 @@ rdnames()
{
NAMES=
if ! contains_something "$XENDOMAINS_AUTO"
- then
+ then
return
fi
for dom in $XENDOMAINS_AUTO/*; do
rdname $dom
- if test -z $NAMES; then
- NAMES=$NM;
+ if test -z $NAMES; then
+ NAMES=$NM;
else
NAMES="$NAMES|$NM"
fi
@@ -232,7 +232,7 @@ is_running()
while read LN; do
parseln "$LN" || continue
if test $id = 0; then continue; fi
- case $name in
+ case $name in
($NM)
RC=0
;;
@@ -241,11 +241,11 @@ is_running()
return $RC
}
-start()
+start()
{
- if [ -f $LOCKFILE ]; then
+ if [ -f $LOCKFILE ]; then
echo -e "xendomains already running (lockfile exists)"
- return;
+ return;
fi
saved_domains=" "
@@ -285,10 +285,10 @@ start()
# XENDOMAINS_AUTO - they could just be symlinks to files elsewhere
# Create all domains with config files in XENDOMAINS_AUTO.
- # TODO: We should record which domain name belongs
+ # TODO: We should record which domain name belongs
# so we have the option to selectively shut down / migrate later
# If a domain statefile from $XENDOMAINS_SAVE matches a domain name
- # in $XENDOMAINS_AUTO, do not try to start that domain; if it didn't
+ # in $XENDOMAINS_AUTO, do not try to start that domain; if it didn't
# restore correctly it requires administrative attention.
for dom in $XENDOMAINS_AUTO/*; do
echo -n " ${dom##*/}"
@@ -349,14 +349,14 @@ watchdog_xencmd()
read PSF PSUID PSPID PSPPID < <(echo "$PSAX")
# kill $CMD $1
kill $PSPID >/dev/null 2>&1
-
+
echo -e .
}
stop()
{
exec 3>&2 2> /dev/null
-
+
# Collect list of domains to shut down
if test "$XENDOMAINS_AUTO_ONLY" = "true"; then
rdnames
@@ -380,7 +380,7 @@ stop()
esac
"
fi
- # XENDOMAINS_SYSRQ chould be something like just "s"
+ # XENDOMAINS_SYSRQ chould be something like just "s"
# or "s e i u" or even "s e s i u o"
# for the latter, you should set XENDOMAINS_USLEEP to 1200000 or so
if test -n "$XENDOMAINS_SYSRQ"; then
@@ -413,7 +413,7 @@ stop()
kill $WDOG_PID >/dev/null 2>&1
else
kill $WDOG_PID >/dev/null 2>&1
-
+
echo -e .
usleep 1000
continue
@@ -472,7 +472,7 @@ stop()
# Unconditionally delete lock file
rm -f $LOCKFILE
-
+
exec 2>&3
}
@@ -482,7 +482,7 @@ check_domain_up()
while read LN; do
parseln "$LN" || continue
if test $id = 0; then continue; fi
- case $name in
+ case $name in
($1)
return 0
;;
@@ -501,9 +501,9 @@ check_all_auto_domains_up()
for nm in $XENDOMAINS_AUTO/*; do
rdname $nm
found=0
- if check_domain_up "$NM"; then
+ if check_domain_up "$NM"; then
echo -n " $name"
- else
+ else
missing="$missing $NM"
fi
done
@@ -516,7 +516,7 @@ check_all_auto_domains_up()
check_all_saved_domains_up()
{
- if ! contains_something "$XENDOMAINS_SAVE"
+ if ! contains_something "$XENDOMAINS_SAVE"
then
return 0
fi
@@ -563,8 +563,8 @@ case "$1" in
;;
status)
- echo -n "Checking for xendomains:"
- if test ! -f $LOCKFILE; then
+ echo -n "Checking for xendomains:"
+ if test ! -f $LOCKFILE; then
rc_failed 3
else
check_all_auto_domains_up
--
2.0.0.rc3.18.g00a5b79
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 08/14] tools/xendomains: move to libexec and use a smaller init helper
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (6 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 07/14] tools/xendomains: do space cleanups Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 09/14] autoconf: xen: force a refresh with autoconf Luis R. Rodriguez
` (5 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, Luis R. Rodriguez,
Jan Rękorajski, Ian Jackson, Jacek Konieczny, M A Young
From: "Luis R. Rodriguez" <mcgrof@suse.com>
The xendomains script can be reused with systemd systems as it
does not control services or sockets per se, but does a one shot
scrape of domUs it needs start bring up, stop, reload so we're
going to reuse it. This moves the core of the script to libexec
and leaves only a helper on init.
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>
---
tools/hotplug/Linux/Makefile | 3 +
tools/hotplug/Linux/init.d/xendomains | 635 +++-------------------------
tools/hotplug/Linux/{init.d => }/xendomains | 0
3 files changed, 53 insertions(+), 585 deletions(-)
rewrite tools/hotplug/Linux/init.d/xendomains (95%)
rename tools/hotplug/Linux/{init.d => }/xendomains (100%)
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 4874ec5..d5de9e6 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -3,6 +3,7 @@ include $(XEN_ROOT)/tools/Rules.mk
# Init scripts.
XENDOMAINS_INITD = init.d/xendomains
+XENDOMAINS_LIBEXEC = xendomains
XENDOMAINS_SYSCONFIG = init.d/sysconfig.xendomains
XENCOMMONS_INITD = init.d/xencommons
@@ -45,6 +46,8 @@ install: all install-initd install-scripts install-udev
install-initd:
[ -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)
+ $(INSTALL_PROG) $(XENDOMAINS_LIBEXEC) $(DESTDIR)$(LIBEXEC)
$(INSTALL_PROG) $(XENDOMAINS_INITD) $(DESTDIR)$(INITD_DIR)
$(INSTALL_DATA) $(XENDOMAINS_SYSCONFIG) $(DESTDIR)$(SYSCONFIG_DIR)/xendomains
$(INSTALL_PROG) $(XENCOMMONS_INITD) $(DESTDIR)$(INITD_DIR)
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/init.d/xendomains
dissimilarity index 95%
index 587568d..d0122fc 100644
--- a/tools/hotplug/Linux/init.d/xendomains
+++ b/tools/hotplug/Linux/init.d/xendomains
@@ -1,585 +1,50 @@
-#!/bin/bash
-#
-# /etc/init.d/xendomains
-# Start / stop domains automatically when domain 0 boots / shuts down.
-#
-# chkconfig: 345 99 00
-# description: Start / stop Xen domains.
-#
-# This script offers fairly basic functionality. It should work on Redhat
-# but also on LSB-compliant SuSE releases and on Debian with the LSB package
-# installed. (LSB is the Linux Standard Base)
-#
-# Based on the example in the "Designing High Quality Integrated Linux
-# Applications HOWTO" by Avi Alkalay
-# <http://www.tldp.org/HOWTO/HighQuality-Apps-HOWTO/>
-#
-### BEGIN INIT INFO
-# Provides: xendomains
-# Required-Start: $syslog $remote_fs xenstored xenconsoled
-# Should-Start: xend
-# Required-Stop: $syslog $remote_fs xenstored xenconsoled
-# Should-Stop: xend
-# Default-Start: 2 3 5
-# Default-Stop: 0 1 6
-# Short-Description: Start/stop secondary xen domains
-# Description: Start / stop domains automatically when domain 0
-# boots / shuts down.
-### END INIT INFO
-
-. /etc/xen/scripts/hotplugpath.sh
-
-CMD=${SBINDIR}/xl
-HEADCOMP="Xen saved domain"
-$CMD list &> /dev/null
-if test $? -ne 0
-then
- CMD=${SBINDIR}/xm
- HEADCOMP="LinuxGuestRecord"
-fi
-
-$CMD list &> /dev/null
-if test $? -ne 0
-then
- exit 0;
-fi
-
-# Correct exit code would probably be 5, but it's enough
-# if xend complains if we're not running as privileged domain
-if ! [ -e /proc/xen/privcmd ]; then
- exit 0
-fi
-
-# See docs/misc/distro_mapping.txt
-if [ -d /var/lock/subsys ]; then
- LOCKFILE=/var/lock/subsys/xendomains
-else
- LOCKFILE=/var/lock/xendomains
-fi
-
-if [ -d /etc/sysconfig ]; then
- XENDOM_CONFIG=/etc/sysconfig/xendomains
-else
- XENDOM_CONFIG=/etc/default/xendomains
-fi
-
-test -r $XENDOM_CONFIG || { echo "$XENDOM_CONFIG not existing";
- if [ "$1" = "stop" ]; then exit 0;
- else exit 6; fi; }
-
-. $XENDOM_CONFIG
-
-# Use the SUSE rc_ init script functions;
-# emulate them on LSB, RH and other systems
-if test -e /etc/rc.status; then
- # SUSE rc script library
- . /etc/rc.status
-else
- _cmd=$1
- declare -a _SMSG
- if test "${_cmd}" = "status"; then
- _SMSG=(running dead dead unused unknown)
- _RC_UNUSED=3
- else
- _SMSG=(done failed failed missed failed skipped unused failed failed)
- _RC_UNUSED=6
- fi
- if test -e /etc/init.d/functions; then
- # REDHAT
- . /etc/init.d/functions
- echo_rc()
- {
- #echo -n " [${_SMSG[${_RC_RV}]}] "
- if test ${_RC_RV} = 0; then
- success " [${_SMSG[${_RC_RV}]}] "
- else
- failure " [${_SMSG[${_RC_RV}]}] "
- fi
- }
- elif test -e /lib/lsb/init-functions; then
- # LSB
- . /lib/lsb/init-functions
- if alias log_success_msg >/dev/null 2>/dev/null; then
- echo_rc()
- {
- echo " [${_SMSG[${_RC_RV}]}] "
- }
- else
- echo_rc()
- {
- if test ${_RC_RV} = 0; then
- log_success_msg " [${_SMSG[${_RC_RV}]}] "
- else
- log_failure_msg " [${_SMSG[${_RC_RV}]}] "
- fi
- }
- fi
- else
- # emulate it
- echo_rc()
- {
- echo " [${_SMSG[${_RC_RV}]}] "
- }
- fi
- rc_reset() { _RC_RV=0; }
- rc_failed()
- {
- if test -z "$1"; then
- _RC_RV=1;
- elif test "$1" != "0"; then
- _RC_RV=$1;
- fi
- return ${_RC_RV}
- }
- rc_check()
- {
- return rc_failed $?
- }
- rc_status()
- {
- rc_failed $?
- if test "$1" = "-r"; then _RC_RV=0; shift; fi
- if test "$1" = "-s"; then rc_failed 5; echo_rc; rc_failed 3; shift; fi
- if test "$1" = "-u"; then rc_failed ${_RC_UNUSED}; echo_rc; rc_failed 3; shift; fi
- if test "$1" = "-v"; then echo_rc; shift; fi
- if test "$1" = "-r"; then _RC_RV=0; shift; fi
- return ${_RC_RV}
- }
- rc_exit() { exit ${_RC_RV}; }
- rc_active()
- {
- if test -z "$RUNLEVEL"; then read RUNLEVEL REST < <(/sbin/runlevel); fi
- if test -e /etc/init.d/S[0-9][0-9]${1}; then return 0; fi
- return 1
- }
-fi
-
-if ! which usleep >&/dev/null
-then
- usleep()
- {
- if [ -n "$1" ]
- then
- sleep $(( $1 / 1000000 ))
- fi
- }
-fi
-
-# Reset status of this service
-rc_reset
-
-##
-# Returns 0 (success) if the given parameter names a directory, and that
-# directory is not empty.
-#
-contains_something()
-{
- if [ -d "$1" ] && [ `/bin/ls $1 | wc -l` -gt 0 ]
- then
- return 0
- else
- return 1
- fi
-}
-
-# read name from xen config file
-rdname()
-{
- NM=$($CMD create --quiet --dryrun --defconfig "$1" |
- sed -n 's/^.*(name \(.*\))$/\1/p;s/^.*"name": "\(.*\)",$/\1/p')
-}
-
-rdnames()
-{
- NAMES=
- if ! contains_something "$XENDOMAINS_AUTO"
- then
- return
- fi
- for dom in $XENDOMAINS_AUTO/*; do
- rdname $dom
- if test -z $NAMES; then
- NAMES=$NM;
- else
- NAMES="$NAMES|$NM"
- fi
- done
-}
-
-LIST_GREP='(domain\|(domid\|(name\|^ {$\|"name":\|"domid":'
-parseln()
-{
- if [[ "$1" =~ '(domain' ]] || [[ "$1" = "{" ]]; then
- name=;id=
- elif [[ "$1" =~ '(name' ]]; then
- name=$(echo $1 | sed -e 's/^.*(name \(.*\))$/\1/')
- elif [[ "$1" =~ '(domid' ]]; then
- id=$(echo $1 | sed -e 's/^.*(domid \(.*\))$/\1/')
- elif [[ "$1" =~ '"name":' ]]; then
- name=$(echo $1 | sed -e 's/^.*"name": "\(.*\)",$/\1/')
- elif [[ "$1" =~ '"domid":' ]]; then
- id=$(echo $1 | sed -e 's/^.*"domid": \(.*\),$/\1/')
- fi
-
- [ -n "$name" -a -n "$id" ] && return 0 || return 1
-}
-
-is_running()
-{
- rdname $1
- RC=1
- name=;id=
- while read LN; do
- parseln "$LN" || continue
- if test $id = 0; then continue; fi
- case $name in
- ($NM)
- RC=0
- ;;
- esac
- done < <($CMD list -l | grep "$LIST_GREP")
- return $RC
-}
-
-start()
-{
- if [ -f $LOCKFILE ]; then
- echo -e "xendomains already running (lockfile exists)"
- return;
- fi
-
- saved_domains=" "
- if [ "$XENDOMAINS_RESTORE" = "true" ] &&
- contains_something "$XENDOMAINS_SAVE"
- then
- mkdir -p $(dirname "$LOCKFILE")
- touch $LOCKFILE
- echo -n "Restoring Xen domains:"
- saved_domains=`ls $XENDOMAINS_SAVE`
- for dom in $XENDOMAINS_SAVE/*; do
- if [ -f $dom ] ; then
- HEADER=`head -c 16 $dom | head -n 1 2> /dev/null`
- if [ "$HEADER" = "$HEADCOMP" ]; then
- echo -n " ${dom##*/}"
- XMR=`$CMD restore $dom 2>&1 1>/dev/null`
- #$CMD restore $dom
- if [ $? -ne 0 ]; then
- echo -e "\nAn error occurred while restoring domain ${dom##*/}:\n$XMR"
- rc_failed $?
- echo -e '!'
- else
- # mv $dom ${dom%/*}/.${dom##*/}
- rm $dom
- fi
- fi
- fi
- done
- echo -e
- fi
-
- if contains_something "$XENDOMAINS_AUTO"
- then
- touch $LOCKFILE
- echo -n "Starting auto Xen domains:"
- # We expect config scripts for auto starting domains to be in
- # XENDOMAINS_AUTO - they could just be symlinks to files elsewhere
-
- # Create all domains with config files in XENDOMAINS_AUTO.
- # TODO: We should record which domain name belongs
- # so we have the option to selectively shut down / migrate later
- # If a domain statefile from $XENDOMAINS_SAVE matches a domain name
- # in $XENDOMAINS_AUTO, do not try to start that domain; if it didn't
- # restore correctly it requires administrative attention.
- for dom in $XENDOMAINS_AUTO/*; do
- echo -n " ${dom##*/}"
- shortdom=$(echo $dom | sed -n 's/^.*\/\(.*\)$/\1/p')
- echo $saved_domains | grep -w $shortdom > /dev/null
- if [ $? -eq 0 ] || is_running $dom; then
- echo -n "(skip)"
- else
- XMC=`$CMD create --quiet --defconfig $dom`
- if [ $? -ne 0 ]; then
- echo -e "\nAn error occurred while creating domain ${dom##*/}: $XMC\n"
- rc_failed $?
- echo -e '!'
- else
- usleep $XENDOMAINS_CREATE_USLEEP
- fi
- fi
- done
- fi
-}
-
-all_zombies()
-{
- name=;id=
- while read LN; do
- parseln "$LN" || continue
- if test $id = 0; then continue; fi
- if test "$state" != "-b---d" -a "$state" != "-----d"; then
- return 1;
- fi
- done < <($CMD list -l | grep "$LIST_GREP")
- return 0
-}
-
-# Wait for max $XENDOMAINS_STOP_MAXWAIT for $CMD $1 to finish;
-# if it has not exited by that time kill it, so the init script will
-# succeed within a finite amount of time; if $2 is nonnull, it will
-# kill the command as well as soon as no domain (except for zombies)
-# are left (used for shutdown --all). Third parameter, if any, suppresses
-# output of dots per working state (formatting issues)
-watchdog_xencmd()
-{
- if test -z "$XENDOMAINS_STOP_MAXWAIT" -o "$XENDOMAINS_STOP_MAXWAIT" = "0"; then
- exit
- fi
-
- usleep 20000
- for no in `seq 0 $XENDOMAINS_STOP_MAXWAIT`; do
- # exit if $CMD save/migrate/shutdown is finished
- PSAX=`ps axlw | grep "$CMD $1" | grep -v grep`
- if test -z "$PSAX"; then exit; fi
- if ! test -n "$3"; then echo -n '.'; fi
- sleep 1
- # go to kill immediately if there's only zombies left
- if all_zombies && test -n "$2"; then break; fi
- done
- sleep 1
- read PSF PSUID PSPID PSPPID < <(echo "$PSAX")
- # kill $CMD $1
- kill $PSPID >/dev/null 2>&1
-
- echo -e .
-}
-
-stop()
-{
- exec 3>&2 2> /dev/null
-
- # Collect list of domains to shut down
- if test "$XENDOMAINS_AUTO_ONLY" = "true"; then
- rdnames
- fi
- echo -n "Shutting down Xen domains:"
- name=;id=
- while read LN; do
- parseln "$LN" || continue
- if test $id = 0; then continue; fi
- echo -n " $name"
- if test "$XENDOMAINS_AUTO_ONLY" = "true"; then
- eval "
- case \"\$name\" in
- ($NAMES)
- # nothing
- ;;
- (*)
- echo -e '(skip)'
- continue
- ;;
- esac
- "
- fi
- # XENDOMAINS_SYSRQ chould be something like just "s"
- # or "s e i u" or even "s e s i u o"
- # for the latter, you should set XENDOMAINS_USLEEP to 1200000 or so
- if test -n "$XENDOMAINS_SYSRQ"; then
- for sysrq in $XENDOMAINS_SYSRQ; do
- echo -n "(SR-$sysrq)"
- XMR=`$CMD sysrq $id $sysrq 2>&1 1>/dev/null`
- if test $? -ne 0; then
- echo -e "\nAn error occurred while doing sysrq on domain:\n$XMR\n"
- rc_failed $?
- echo -n '!'
- fi
- # usleep just ignores empty arg
- usleep $XENDOMAINS_USLEEP
- done
- fi
- if test "$state" = "-b---d" -o "$state" = "-----d"; then
- echo -n "(zomb)"
- continue
- fi
- if test -n "$XENDOMAINS_MIGRATE"; then
- echo -n "(migr)"
- watchdog_xencmd migrate &
- WDOG_PID=$!
- XMR=`$CMD migrate $id $XENDOMAINS_MIGRATE 2>&1 1>/dev/null`
- if test $? -ne 0; then
- echo -e "\nAn error occurred while migrating domain:\n$XMR\n"
- rc_failed $?
- echo -e '!'
-
- kill $WDOG_PID >/dev/null 2>&1
- else
- kill $WDOG_PID >/dev/null 2>&1
-
- echo -e .
- usleep 1000
- continue
- fi
- fi
- if test -n "$XENDOMAINS_SAVE"; then
- echo -n "(save)"
- watchdog_xencmd save &
- WDOG_PID=$!
- mkdir -p "$XENDOMAINS_SAVE"
- XMR=`$CMD save $id $XENDOMAINS_SAVE/$name 2>&1 1>/dev/null`
- if test $? -ne 0; then
- echo -e "\nAn error occurred while saving domain:\n$XMR\n"
- rc_failed $?
- echo -e '!'
- kill $WDOG_PID >/dev/null 2>&1
- else
- kill $WDOG_PID >/dev/null 2>&1
- echo -e .
- usleep 1000
- continue
- fi
- fi
- if test -n "$XENDOMAINS_SHUTDOWN"; then
- # XENDOMAINS_SHUTDOWN should be "--wait"
- echo -n "(shut)"
- watchdog_xencmd shutdown &
- WDOG_PID=$!
- XMR=`$CMD shutdown $XENDOMAINS_SHUTDOWN $id 2>&1 1>/dev/null`
- if test $? -ne 0; then
- echo -e "\nAn error occurred while shutting down domain:\n$XMR\n"
- rc_failed $?
- echo -e '!'
- fi
- kill $WDOG_PID >/dev/null 2>&1
- fi
- done < <($CMD list -l | grep "$LIST_GREP")
-
- # NB. this shuts down ALL Xen domains (politely), not just the ones in
- # AUTODIR/*
- # This is because it's easier to do ;-) but arguably if this script is run
- # on system shutdown then it's also the right thing to do.
- if ! all_zombies && test -n "$XENDOMAINS_SHUTDOWN_ALL"; then
- # XENDOMAINS_SHUTDOWN_ALL should be "--all --wait"
- echo -n " SHUTDOWN_ALL "
- watchdog_xencmd shutdown 1 false &
- WDOG_PID=$!
- XMR=`$CMD shutdown $XENDOMAINS_SHUTDOWN_ALL 2>&1 1>/dev/null`
- if test $? -ne 0; then
- echo -e "\nAn error occurred while shutting down all domains: $XMR\n"
- rc_failed $?
- echo -e '!'
- fi
- kill $WDOG_PID >/dev/null 2>&1
- fi
-
- # Unconditionally delete lock file
- rm -f $LOCKFILE
-
- exec 2>&3
-}
-
-check_domain_up()
-{
- name=;id=
- while read LN; do
- parseln "$LN" || continue
- if test $id = 0; then continue; fi
- case $name in
- ($1)
- return 0
- ;;
- esac
- done < <($CMD list -l | grep "$LIST_GREP")
- return 1
-}
-
-check_all_auto_domains_up()
-{
- if ! contains_something "$XENDOMAINS_AUTO"
- then
- return 0
- fi
- missing=
- for nm in $XENDOMAINS_AUTO/*; do
- rdname $nm
- found=0
- if check_domain_up "$NM"; then
- echo -n " $name"
- else
- missing="$missing $NM"
- fi
- done
- if test -n "$missing"; then
- echo -n " MISS AUTO:$missing"
- return 1
- fi
- return 0
-}
-
-check_all_saved_domains_up()
-{
- if ! contains_something "$XENDOMAINS_SAVE"
- then
- return 0
- fi
- missing=`/bin/ls $XENDOMAINS_SAVE`
- echo -n " MISS SAVED: " $missing
- return 1
-}
-
-# This does NOT necessarily restart all running domains: instead it
-# stops all running domains and then boots all the domains specified in
-# AUTODIR. If other domains have been started manually then they will
-# not get restarted.
-# Commented out to avoid confusion!
-
-restart()
-{
- stop
- start
-}
-
-reload()
-{
- restart
-}
-
-
-case "$1" in
- start)
- start
- rc_status
- if test -f $LOCKFILE; then rc_status -v; fi
- ;;
-
- stop)
- stop
- rc_status -v
- ;;
-
- restart)
- restart
- ;;
- reload)
- reload
- ;;
-
- status)
- echo -n "Checking for xendomains:"
- if test ! -f $LOCKFILE; then
- rc_failed 3
- else
- check_all_auto_domains_up
- rc_status
- check_all_saved_domains_up
- rc_status
- fi
- rc_status -v
- ;;
-
- *)
- echo "Usage: $0 {start|stop|restart|reload|status}"
- rc_failed 3
- rc_status -v
- ;;
-esac
-
-rc_exit
+#!/bin/bash
+#
+# /etc/init.d/xendomains
+# Wrapper to start / stop domains automatically when domain 0 boots / shuts down
+#
+# chkconfig: 345 99 00
+# description: Helper to start / stop Xen domains.
+#
+# This script is a wrapper init helper for the real workload horse script.
+# It should work on LSB-compliant systems.
+#
+### BEGIN INIT INFO
+# Provides: xendomains
+# Required-Start: $syslog $remote_fs xenstored xenconsoled
+# Should-Start: xend
+# Required-Stop: $syslog $remote_fs xenstored xenconsoled
+# Should-Stop: xend
+# Default-Start: 2 3 5
+# Default-Stop: 0 1 6
+# Short-Description: Wrapper to start/stop secondary xen domains
+# Description: Wrapper for starting / stopping domains automatically
+# when domain 0 boots / shuts down on systems using init.
+# The $SBINDIR/xendomains helper is shared between init and
+# systemd systems.
+### END INIT INFO
+
+. /etc/xen/scripts/hotplugpath.sh
+
+case "$1" in
+ start)
+ $SBINDIR/xendomains start
+ ;;
+ stop)
+ $SBINDIR/xendomains stop
+ ;;
+ restart)
+ $SBINDIR/xendomains restart
+ ;;
+ reload)
+ $SBINDIR/xendomains reload
+ ;;
+ status)
+ $SBINDIR/xendomains status
+ ;;
+ *)
+ echo "Usage: $0 {start|stop|restart|reload|status}"
+ exit 3
+ ;;
+esac
+exit $?
diff --git a/tools/hotplug/Linux/init.d/xendomains b/tools/hotplug/Linux/xendomains
similarity index 100%
rename from tools/hotplug/Linux/init.d/xendomains
rename to tools/hotplug/Linux/xendomains
--
2.0.0.rc3.18.g00a5b79
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 09/14] autoconf: xen: force a refresh with autoconf
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (7 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 08/14] tools/xendomains: move to libexec and use a smaller init helper Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-21 15:07 ` Ian Campbell
2014-05-20 12:31 ` [PATCH v5 10/14] autoconf: update m4/pkg.m4 Luis R. Rodriguez
` (4 subsequent siblings)
13 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Keir Fraser, Ian Campbell, Tim Deegan, Luis R. Rodriguez,
Ian Jackson, Jan Beulich
From: "Luis R. Rodriguez" <mcgrof@suse.com>
With some new functionality introduced we can't keep around the old cache,
but more specifically at times autogen.sh can produce inconsistent
results without considering all files obsolete. The cost of considering
all files obsolete is small so just force it.
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>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
autogen.sh | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index b5c9688..2be8360 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,12 +1,12 @@
#!/bin/sh -e
-autoconf
+autoconf -f
( cd tools
- autoconf
+ autoconf -f
autoheader
)
( cd stubdom
- autoconf
+ autoconf -f
)
( cd docs
- autoconf
+ autoconf -f
)
--
2.0.0.rc3.18.g00a5b79
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 09/14] autoconf: xen: force a refresh with autoconf
2014-05-20 12:31 ` [PATCH v5 09/14] autoconf: xen: force a refresh with autoconf Luis R. Rodriguez
@ 2014-05-21 15:07 ` Ian Campbell
2014-05-21 17:35 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 15:07 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Tim Deegan, Luis R. Rodriguez, Ian Jackson,
Jan Beulich, xen-devel
On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> With some new functionality introduced we can't keep around the old cache,
> but more specifically at times autogen.sh can produce inconsistent
> results without considering all files obsolete. The cost of considering
> all files obsolete is small so just force it.
>
> 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>
> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(we tend to order Cc, Ack, S-o-b in chronological order BTW, so your
S-o-b, then CC'd, then {Acked,Reviewed,etc}-by in the order they come
in)
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 09/14] autoconf: xen: force a refresh with autoconf
2014-05-21 15:07 ` Ian Campbell
@ 2014-05-21 17:35 ` Luis R. Rodriguez
0 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 17:35 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Luis R. Rodriguez, Ian Jackson, Tim Deegan,
Jan Beulich, xen-devel
On Wed, May 21, 2014 at 04:07:12PM +0100, Ian Campbell wrote:
> On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > With some new functionality introduced we can't keep around the old cache,
> > but more specifically at times autogen.sh can produce inconsistent
> > results without considering all files obsolete. The cost of considering
> > all files obsolete is small so just force it.
> >
> > 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>
> > Acked-by: Roger Pau Monné <roger.pau@citrix.com>
> > Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> (we tend to order Cc, Ack, S-o-b in chronological order BTW, so your
> S-o-b, then CC'd, then {Acked,Reviewed,etc}-by in the order they come
> in)
OK.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v5 10/14] autoconf: update m4/pkg.m4
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (8 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 09/14] autoconf: xen: force a refresh with autoconf Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place Luis R. Rodriguez
` (3 subsequent siblings)
13 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Keir Fraser, Ian Campbell, Tim Deegan, Luis R. Rodriguez,
Ian Jackson, Jan Beulich
From: "Luis R. Rodriguez" <mcgrof@suse.com>
The provenance of the m4 pkg.m4 macro library was not documented
and it was not clear how and if we can update this without breaking
things. Document where this comes from, update us to the latest
release from git and put a warning about avoiding private evolutions
so that instead things go upstream.
The pkg-config m4 macro library comes from the upstream pkg-config
git repository [0]. If you update the m4 library update this file
with provenance and last commit ID information. For documentation
on how to use this read the pkg-config(1) man page.
Tree: git://anongit.freedesktop.org/pkg-config
The last synch was from commit:
commit 4f0084d9d3b8726a797a373c7ec5e406000995d0
Author: Dan Nicholson <dbn.lists@gmail.com>
Date: Mon Feb 3 15:59:18 2014 -0800
glib: Fix Makefiles to suppress warnings from automake
With the newly added glib.mk, some of the noinst_* variables need to use
+= in the evaluation to avoid multiple definition warnings from
automake.
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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
Please run ./autgen.sh after this patch is applied.
m4/README.source | 28 ++++++++++++++++++
m4/pkg.m4 | 88 ++++++++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 110 insertions(+), 6 deletions(-)
create mode 100644 m4/README.source
diff --git a/m4/README.source b/m4/README.source
new file mode 100644
index 0000000..76f7c5a
--- /dev/null
+++ b/m4/README.source
@@ -0,0 +1,28 @@
+About
+=====
+This documents the upstream sources for the different slew of different
+m4 sources we have picked up or developed.
+
+pkg.m4
+======
+The pkg-config m4 macro library comes from the upstream pkg-config
+git repository [0]. If you update the m4 library update this file
+with provenance and last commit ID information. For documentation
+on how to use this read the pkg-config(1) man page.
+
+Do not modify this file yourself, if you want to evolve it send
+patches upstream and then synch back here.
+
+Tree: git://anongit.freedesktop.org/pkg-config
+
+The last synch was from commit:
+
+commit 4f0084d9d3b8726a797a373c7ec5e406000995d0
+Author: Dan Nicholson <dbn.lists@gmail.com>
+Date: Mon Feb 3 15:59:18 2014 -0800
+
+ glib: Fix Makefiles to suppress warnings from automake
+
+ With the newly added glib.mk, some of the noinst_* variables need to use
+ += in the evaluation to avoid multiple definition warnings from
+ automake.
diff --git a/m4/pkg.m4 b/m4/pkg.m4
index 9bb3e06..62995f0 100644
--- a/m4/pkg.m4
+++ b/m4/pkg.m4
@@ -26,7 +26,8 @@
# ----------------------------------
AC_DEFUN([PKG_PROG_PKG_CONFIG],
[m4_pattern_forbid([^_?PKG_[A-Z_]+$])
-m4_pattern_allow([^PKG_CONFIG(_PATH)?$])
+m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$])
+m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$])
AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])
AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path])
AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path])
@@ -72,7 +73,8 @@ m4_define([_PKG_CONFIG],
pkg_cv_[]$1="$$1"
elif test -n "$PKG_CONFIG"; then
PKG_CHECK_EXISTS([$3],
- [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`],
+ [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`
+ test "x$?" != "x0" && pkg_failed=yes ],
[pkg_failed=yes])
else
pkg_failed=untried
@@ -120,9 +122,9 @@ if test $pkg_failed = yes; then
AC_MSG_RESULT([no])
_PKG_SHORT_ERRORS_SUPPORTED
if test $_pkg_short_errors_supported = yes; then
- $1[]_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors "$2" 2>&1`
+ $1[]_PKG_ERRORS=`$PKG_CONFIG --short-errors --print-errors --cflags --libs "$2" 2>&1`
else
- $1[]_PKG_ERRORS=`$PKG_CONFIG --print-errors "$2" 2>&1`
+ $1[]_PKG_ERRORS=`$PKG_CONFIG --print-errors --cflags --libs "$2" 2>&1`
fi
# Put the nasty error message in config.log where it belongs
echo "$$1[]_PKG_ERRORS" >&AS_MESSAGE_LOG_FD
@@ -135,7 +137,7 @@ $$1_PKG_ERRORS
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
-_PKG_TEXT])dnl
+_PKG_TEXT])[]dnl
])
elif test $pkg_failed = untried; then
AC_MSG_RESULT([no])
@@ -146,7 +148,7 @@ path to pkg-config.
_PKG_TEXT
-To get pkg-config, see <http://pkg-config.freedesktop.org/>.])dnl
+To get pkg-config, see <http://pkg-config.freedesktop.org/>.])[]dnl
])
else
$1[]_CFLAGS=$pkg_cv_[]$1[]_CFLAGS
@@ -155,3 +157,77 @@ else
$3
fi[]dnl
])# PKG_CHECK_MODULES
+
+
+# PKG_CHECK_MODULES_STATIC(VARIABLE-PREFIX, MODULES, [ACTION-IF-FOUND],
+# [ACTION-IF-NOT-FOUND])
+# ---------------------------------------------------------------------
+# Checks for existence of MODULES and gathers its build flags with
+# static libraries enabled. Sets VARIABLE-PREFIX_CFLAGS from --cflags
+# and VARIABLE-PREFIX_LIBS from --libs.
+#
+# Note that if there is a possibility the first call to
+# PKG_CHECK_MODULES_STATIC might not happen, you should be sure to include
+# an explicit call to PKG_PROG_PKG_CONFIG in your configure.ac.
+AC_DEFUN([PKG_CHECK_MODULES_STATIC],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+_save_PKG_CONFIG=$PKG_CONFIG
+PKG_CONFIG="$PKG_CONFIG --static"
+PKG_CHECK_MODULES($@)
+PKG_CONFIG=$_save_PKG_CONFIG[]dnl
+])
+
+
+# PKG_INSTALLDIR(DIRECTORY)
+# -------------------------
+# Substitutes the variable pkgconfigdir as the location where a module
+# should install pkg-config .pc files. By default the directory is
+# $libdir/pkgconfig, but the default can be changed by passing
+# DIRECTORY. The user can override through the --with-pkgconfigdir
+# parameter.
+AC_DEFUN([PKG_INSTALLDIR],
+[m4_pushdef([pkg_default], [m4_default([$1], ['${libdir}/pkgconfig'])])
+m4_pushdef([pkg_description],
+ [pkg-config installation directory @<:@]pkg_default[@:>@])
+AC_ARG_WITH([pkgconfigdir],
+ [AS_HELP_STRING([--with-pkgconfigdir], pkg_description)],,
+ [with_pkgconfigdir=]pkg_default)
+AC_SUBST([pkgconfigdir], [$with_pkgconfigdir])
+m4_popdef([pkg_default])
+m4_popdef([pkg_description])
+]) dnl PKG_INSTALLDIR
+
+
+# PKG_NOARCH_INSTALLDIR(DIRECTORY)
+# -------------------------
+# Substitutes the variable noarch_pkgconfigdir as the location where a
+# module should install arch-independent pkg-config .pc files. By
+# default the directory is $datadir/pkgconfig, but the default can be
+# changed by passing DIRECTORY. The user can override through the
+# --with-noarch-pkgconfigdir parameter.
+AC_DEFUN([PKG_NOARCH_INSTALLDIR],
+[m4_pushdef([pkg_default], [m4_default([$1], ['${datadir}/pkgconfig'])])
+m4_pushdef([pkg_description],
+ [pkg-config arch-independent installation directory @<:@]pkg_default[@:>@])
+AC_ARG_WITH([noarch-pkgconfigdir],
+ [AS_HELP_STRING([--with-noarch-pkgconfigdir], pkg_description)],,
+ [with_noarch_pkgconfigdir=]pkg_default)
+AC_SUBST([noarch_pkgconfigdir], [$with_noarch_pkgconfigdir])
+m4_popdef([pkg_default])
+m4_popdef([pkg_description])
+]) dnl PKG_NOARCH_INSTALLDIR
+
+
+# PKG_CHECK_VAR(VARIABLE, MODULE, CONFIG-VARIABLE,
+# [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+# -------------------------------------------
+# Retrieves the value of the pkg-config variable for the given module.
+AC_DEFUN([PKG_CHECK_VAR],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+AC_ARG_VAR([$1], [value of $3 for $2, overriding pkg-config])dnl
+
+_PKG_CONFIG([$1], [variable="][$3]["], [$2])
+AS_VAR_COPY([$1], [pkg_cv_][$1])
+
+AS_VAR_IF([$1], [""], [$5], [$4])dnl
+])# PKG_CHECK_VAR
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (9 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 10/14] autoconf: update m4/pkg.m4 Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 13:37 ` Jan Beulich
` (2 more replies)
2014-05-20 12:31 ` [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference Luis R. Rodriguez
` (2 subsequent siblings)
13 siblings, 3 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Keir Fraser, Ian Campbell, Tim Deegan, Luis R. Rodriguez,
Ian Jackson, Jan Beulich, Samuel Thibault
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This moves all generic variables to the top level makefile,
tons of files use these so just make them general enough. 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 replaces all that with a two central files, one for
shell scripts and another for C header files. We should later
optimize this further by only having one target file and
generating the two needed from that.
Building the hypervisor and extras/mini-os without requiring configure
is kept supported by providing a default configuration file with
defaults that will be overwritten only if configure is used.
While at it lets add some documentation on the README and enable us
to 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>
---
Please run ./autgen.sh after this patch is applied.
.gitignore | 2 ++
Config.mk | 13 ---------
README | 16 ++++++++++
config/StdGNU.mk | 28 +++++++++---------
config/Toplevel.mk.in | 24 +++++++++++++++
config/defaults.mk | 21 ++++++++++++++
| 13 +++++++++
config/xen-environment-scripts.in | 15 ++++++++++
configure.ac | 9 +++++-
m4/expand_config.m4 | 61 +++++++++++++++++++++++++++++++++++++++
stubdom/Makefile | 17 ++++++-----
stubdom/configure.ac | 3 ++
tools/configure.ac | 3 ++
tools/hotplug/common/Makefile | 6 ++--
tools/libxl/Makefile | 11 ++-----
tools/python/Makefile | 6 ++--
16 files changed, 198 insertions(+), 50 deletions(-)
create mode 100644 config/defaults.mk
create mode 100644 config/xen-environment-header.in
create mode 100644 config/xen-environment-scripts.in
create mode 100644 m4/expand_config.m4
diff --git a/.gitignore b/.gitignore
index 562c262..fd1b627 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,8 @@ config.log
config.status
config.cache
config/Toplevel.mk
+config/xen-environment-scripts
+config/xen-environment-header
build-*
dist/*
diff --git a/Config.mk b/Config.mk
index 6a93533..84f79a0 100644
--- a/Config.mk
+++ b/Config.mk
@@ -166,19 +166,6 @@ define move-if-changed
if ! cmp -s $(1) $(2); then mv -f $(1) $(2); else rm -f $(1); fi
endef
-buildmakevars2file = $(eval $(call buildmakevars2file-closure,$(1)))
-define buildmakevars2file-closure
- .PHONY: genpath
- genpath:
- rm -f $(1).tmp; \
- $(foreach var, \
- SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR \
- XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
- XEN_RUN_DIR XEN_PAGING_DIR, \
- echo "$(var)=\"$($(var))\"" >>$(1).tmp;) \
- $(call move-if-changed,$(1).tmp,$(1))
-endef
-
ifeq ($(debug_symbols),y)
CFLAGS += -g
endif
diff --git a/README b/README
index 9bbe734..079e6a9 100644
--- a/README
+++ b/README
@@ -129,6 +129,22 @@ performed with root privileges.]
versions of those scripts, so that you can copy the dist directory
to another machine and install from that distribution.
+Xen system configuration
+========================
+
+Xen uses a set of variables for system configuration and upon build time,
+because of this these variables are defined on a top level general input
+source and are generated after running ./configure. There are two versions
+of the input files, one for scripts (bash, python) and another for C / header
+files:
+
+ * config/xen-environment-header.in - used to generate config/xen-environment-header
+ * config/xen-environment-scripts.in - used to generate config/xen-environment-scripts
+
+Further documentation can be found on the wiki:
+
+http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
+
Python Runtime Libraries
========================
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index c6439f6..273f1e8 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,3 +1,17 @@
+# These are standard defaults which you can use to avoid having
+# to run ./configure -- you can use this to compile the hypervisor
+# and the mini os:
+#
+# make xen
+# sudo make -C xen install
+#
+# make -C extras/mini-os
+include $(XEN_ROOT)/config/defaults.mk
+
+# This comes from running configure and will override
+# the defaults.
+-include $(XEN_ROOT)/config/Toplevel.mk
+
AS = $(CROSS_COMPILE)as
LD = $(CROSS_COMPILE)ld
ifeq ($(clang),y)
@@ -27,24 +41,10 @@ INSTALL_DIR = $(INSTALL) -d -m0755 -p
INSTALL_DATA = $(INSTALL) -m0644 -p
INSTALL_PROG = $(INSTALL) -m0755 -p
-PREFIX ?= /usr
-BINDIR = $(PREFIX)/bin
INCLUDEDIR = $(PREFIX)/include
-LIBEXEC = $(PREFIX)/lib/xen/bin
-SHAREDIR = $(PREFIX)/share
MANDIR = $(SHAREDIR)/man
MAN1DIR = $(MANDIR)/man1
MAN8DIR = $(MANDIR)/man8
-SBINDIR = $(PREFIX)/sbin
-XENFIRMWAREDIR = $(PREFIX)/lib/xen/boot
-
-PRIVATE_PREFIX = $(LIBDIR)/xen
-PRIVATE_BINDIR = $(PRIVATE_PREFIX)/bin
-
-CONFIG_DIR = /etc
-XEN_LOCK_DIR = /var/lock
-XEN_RUN_DIR = /var/run/xen
-XEN_PAGING_DIR = /var/lib/xen/xenpaging
SYSCONFIG_DIR = $(CONFIG_DIR)/$(CONFIG_LEAF_DIR)
diff --git a/config/Toplevel.mk.in b/config/Toplevel.mk.in
index 4db7eaf..fc2754c 100644
--- a/config/Toplevel.mk.in
+++ b/config/Toplevel.mk.in
@@ -1 +1,25 @@
SUBSYSTEMS := @SUBSYSTEMS@
+
+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/defaults.mk b/config/defaults.mk
new file mode 100644
index 0000000..d1d3d5a
--- /dev/null
+++ b/config/defaults.mk
@@ -0,0 +1,21 @@
+# Build system defaults, in case you never ran ./configure, this is
+# supported to be able to build the xen hypervisor and the mini os:
+#
+# make xen
+# sudo make -C xen install
+#
+# make -C extras/mini-os
+PREFIX ?= /usr
+BINDIR = $(PREFIX)/bin
+LIBEXEC = $(PREFIX)/lib/xen/bin
+SHAREDIR = $(PREFIX)/share
+SBINDIR = $(PREFIX)/sbin
+XENFIRMWAREDIR = $(PREFIX)/lib/xen/boot
+
+PRIVATE_PREFIX = $(LIBDIR)/xen
+PRIVATE_BINDIR = $(PRIVATE_PREFIX)/bin
+
+CONFIG_DIR = /etc
+XEN_LOCK_DIR = /var/lock
+XEN_RUN_DIR = /var/run/xen
+XEN_PAGING_DIR = /var/lib/xen/xenpaging
--git a/config/xen-environment-header.in b/config/xen-environment-header.in
new file mode 100644
index 0000000..7dd7a53
--- /dev/null
+++ b/config/xen-environment-header.in
@@ -0,0 +1,13 @@
+#define SBINDIR "@SBINDIR@"
+#define BINDIR "@BINDIR@"
+#define LIBEXEC "@LIBEXEC@"
+#define LIBDIR "@LIBDIR@"
+#define SHAREDIR "@SHAREDIR@"
+
+#define PRIVATE_BINDIR "@PRIVATE_BINDIR@"
+#define XENFIRMWAREDIR "@XENFIRMWAREDIR@"
+#define XEN_CONFIG_DIR "@XEN_CONFIG_DIR@"
+#define XEN_SCRIPT_DIR "@XEN_SCRIPT_DIR@"
+#define XEN_LOCK_DIR "@XEN_LOCK_DIR@"
+#define XEN_RUN_DIR "@XEN_RUN_DIR@"
+#define XEN_PAGING_DIR "@XEN_PAGING_DIR@"
diff --git a/config/xen-environment-scripts.in b/config/xen-environment-scripts.in
new file mode 100644
index 0000000..9623231
--- /dev/null
+++ b/config/xen-environment-scripts.in
@@ -0,0 +1,15 @@
+SBINDIR="@SBINDIR@"
+BINDIR="@BINDIR@"
+LIBEXEC="@LIBEXEC@"
+LIBDIR="@LIBDIR@"
+SHAREDIR="@SHAREDIR@"
+
+PRIVATE_BINDIR="@PRIVATE_BINDIR@"
+XENFIRMWAREDIR="@XENFIRMWAREDIR@"
+XEN_CONFIG_DIR="@XEN_CONFIG_DIR@"
+XEN_SCRIPT_DIR="@XEN_SCRIPT_DIR@"
+XEN_LOCK_DIR="@XEN_LOCK_DIR@"
+XEN_LOG_DIR="@XEN_LOG_DIR@"
+XEN_LIB_STORED="@XEN_LIB_STORED@"
+XEN_RUN_DIR="@XEN_RUN_DIR@"
+XEN_PAGING_DIR="@XEN_PAGING_DIR@"
diff --git a/configure.ac b/configure.ac
index 6c14524..3f26a39 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,12 +5,19 @@ 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/xen-environment-scripts
+ config/xen-environment-header
+])
AC_CANONICAL_HOST
m4_include([m4/features.m4])
m4_include([m4/subsystem.m4])
+m4_include([m4/expand_config.m4])
+
+AX_XEN_EXPAND_CONFIG()
dnl mini-os is only ported to certain platforms
case "$host_cpu" in
diff --git a/m4/expand_config.m4 b/m4/expand_config.m4
new file mode 100644
index 0000000..717fcd1
--- /dev/null
+++ b/m4/expand_config.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/stubdom/Makefile b/stubdom/Makefile
index c41de27..f0f624a 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -48,18 +48,19 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
TARGETS=$(STUBDOM_TARGETS)
+STUBDOMPATH="stubdompath.sh"
+
+$(STUBDOMPATH): $(XEN_ROOT)/config/xen-environment-scripts
+ @cp $(XEN_ROOT)/config/xen-environment-scripts $@
+
.PHONY: all
all: build
ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath $(STUBDOM_BUILD)
+build: $(STUBDOMPATH) $(STUBDOM_BUILD)
else
-build: genpath
+build: $(STUBDOMPATH)
endif
-STUBDOMPATH="stubdompath.sh"
-genpath-target = $(call buildmakevars2file,$(STUBDOMPATH))
-$(eval $(genpath-target))
-
##############
# Cross-newlib
##############
@@ -448,9 +449,9 @@ xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
#########
ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme $(STUBDOM_INSTALL)
+install: $(STUBDOMPATH) install-readme $(STUBDOM_INSTALL)
else
-install: genpath
+install: $(STUBDOMPATH)
endif
install-readme:
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index 6468203..d6b0fbf 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -16,6 +16,9 @@ m4_include([../m4/features.m4])
m4_include([../m4/path_or_fail.m4])
m4_include([../m4/depends.m4])
m4_include([../m4/fetcher.m4])
+m4_include([../m4/expand_config.m4])
+
+AX_XEN_EXPAND_CONFIG()
# Enable/disable stub domains
AX_STUBDOM_CONDITIONAL([ioemu-stubdom], [ioemu])
diff --git a/tools/configure.ac b/tools/configure.ac
index 25d7ca3..470894a 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -47,6 +47,9 @@ 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/expand_config.m4])
+
+AX_XEN_EXPAND_CONFIG()
# Enable/disable options
AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
diff --git a/tools/hotplug/common/Makefile b/tools/hotplug/common/Makefile
index 18d87aa..4a63f40 100644
--- a/tools/hotplug/common/Makefile
+++ b/tools/hotplug/common/Makefile
@@ -9,14 +9,14 @@ HOTPLUGPATH="hotplugpath.sh"
XEN_SCRIPTS =
XEN_SCRIPT_DATA = $(HOTPLUGPATH)
-genpath-target = $(call buildmakevars2file,$(HOTPLUGPATH))
-$(eval $(genpath-target))
+$(HOTPLUGPATH): $(XEN_ROOT)/config/xen-environment-scripts
+ @cp $(XEN_ROOT)/config/xen-environment-scripts $@
.PHONY: all
all: build
.PHONY: build
-build: genpath
+build: $(HOTPLUGPATH)
.PHONY: install
install: all install-scripts
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4cfa275..fedfd62 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -97,6 +97,9 @@ TEST_PROGS += $(foreach t, $(LIBXL_TESTS),test_$t)
$(LIBXL_OBJS) $(LIBXL_TEST_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
+_paths.h: $(XEN_ROOT)/config/xen-environment-header
+ @cp $(XEN_ROOT)/config/xen-environment-header $@
+
AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
libxlu_disk_l.h _libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
@@ -141,9 +144,6 @@ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS) \
@rm -f $*.[ch]
$(FLEX) --header-file=$*.h --outfile=$*.c $<
-genpath-target = $(call buildmakevars2file,_paths.h.tmp)
-$(eval $(genpath-target))
-
libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
$(PERL) $^
touch $@
@@ -154,11 +154,6 @@ _%.api-for-check: %.h $(AUTOINCS)
>$@.new
mv -f $@.new $@
-_paths.h: genpath
- sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" $@.tmp >$@.2.tmp
- rm -f $@.tmp
- $(call move-if-changed,$@.2.tmp,$@)
-
_libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
$(PERL) $^ --prefix=libxl >$@.new
$(call move-if-changed,$@.new,$@)
diff --git a/tools/python/Makefile b/tools/python/Makefile
index c433cbe..5556ffa 100644
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -6,11 +6,11 @@ all: build
XENPATH = "xen/util/path.py"
-genpath-target = $(call buildmakevars2file,$(XENPATH))
-$(eval $(genpath-target))
+$(XENPATH): $(XEN_ROOT)/config/xen-environment-scripts
+ @cp $(XEN_ROOT)/config/xen-environment-scripts $@
.PHONY: build
-build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
+build: $(XENPATH) genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
$(XEN_ROOT)/tools/libxl/idl.py
PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
$(XEN_ROOT)/tools/libxl/libxl_types.idl \
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-20 12:31 ` [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place Luis R. Rodriguez
@ 2014-05-20 13:37 ` Jan Beulich
[not found] ` <537B76D1020000780001422C@suse.com>
2014-05-21 15:26 ` Ian Campbell
2 siblings, 0 replies; 71+ messages in thread
From: Jan Beulich @ 2014-05-20 13:37 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Ian Campbell, Tim Deegan, Luis Rodriguez,
Ian Jackson, xen-devel, Samuel Thibault
>>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -1,3 +1,17 @@
> +# These are standard defaults which you can use to avoid having
> +# to run ./configure -- you can use this to compile the hypervisor
> +# and the mini os:
> +#
> +# make xen
> +# sudo make -C xen install
> +#
> +# make -C extras/mini-os
> +include $(XEN_ROOT)/config/defaults.mk
> +
> +# This comes from running configure and will override
> +# the defaults.
> +-include $(XEN_ROOT)/config/Toplevel.mk
So what is the result of running one of the above make invocations
without having run ./configure, then running ./configure before
running the same make invocation (for an incremental update)
again?
> --- /dev/null
> +++ b/config/defaults.mk
> @@ -0,0 +1,21 @@
> +# Build system defaults, in case you never ran ./configure, this is
> +# supported to be able to build the xen hypervisor and the mini os:
> +#
> +# make xen
> +# sudo make -C xen install
> +#
> +# make -C extras/mini-os
> +PREFIX ?= /usr
Presumably this is meant to retain the previous setting from
StdGNU.mk, but being tree-wide this then is kind of in conflict with
the tools default of /usr/local (and I think with the switch to the
latter StdGNU.mk should have been switched too).
Also you appear to be ignoring the similar settings done in
SunOS.mk.
Jan
^ permalink raw reply [flat|nested] 71+ messages in thread[parent not found: <537B76D1020000780001422C@suse.com>]
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
[not found] ` <537B76D1020000780001422C@suse.com>
@ 2014-05-20 17:54 ` Luis R. Rodriguez
2014-05-21 7:32 ` Jan Beulich
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 17:54 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, Ian Campbell, Luis R. Rodriguez, Tim Deegan,
Ian Jackson, xen-devel, Samuel Thibault
On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
> > --- a/config/StdGNU.mk
> > +++ b/config/StdGNU.mk
> > @@ -1,3 +1,17 @@
> > +# These are standard defaults which you can use to avoid having
> > +# to run ./configure -- you can use this to compile the hypervisor
> > +# and the mini os:
> > +#
> > +# make xen
> > +# sudo make -C xen install
> > +#
> > +# make -C extras/mini-os
> > +include $(XEN_ROOT)/config/defaults.mk
> > +
> > +# This comes from running configure and will override
> > +# the defaults.
> > +-include $(XEN_ROOT)/config/Toplevel.mk
>
> So what is the result of running one of the above make invocations
> without having run ./configure, then running ./configure before
> running the same make invocation (for an incremental update)
> again?
In my last v4 you pointed out two targets which you wished to
ensure would not require running configure, both of those targets:
make xen -j $(getconf _NPROCESSORS_ONLN)
make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
I have ensured this in this series and the above change indeed
is what you were looking for.
> > --- /dev/null
> > +++ b/config/defaults.mk
> > @@ -0,0 +1,21 @@
> > +# Build system defaults, in case you never ran ./configure, this is
> > +# supported to be able to build the xen hypervisor and the mini os:
> > +#
> > +# make xen
> > +# sudo make -C xen install
> > +#
> > +# make -C extras/mini-os
> > +PREFIX ?= /usr
>
> Presumably this is meant to retain the previous setting from
> StdGNU.mk, but being tree-wide this then is kind of in conflict with
> the tools default of /usr/local
It would seem that way but ./configure is required to compile tools
and /usr/local/ is actually preserved as the default for tools if no
prefix is specifified, just as before.
> (and I think with the switch to the
> latter StdGNU.mk should have been switched too).
>
> Also you appear to be ignoring the similar settings done in
> SunOS.mk.
Can someone with a Solaris box test the above similar changes?
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-20 17:54 ` Luis R. Rodriguez
@ 2014-05-21 7:32 ` Jan Beulich
2014-05-21 8:03 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Jan Beulich @ 2014-05-21 7:32 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Ian Campbell, Luis R. Rodriguez, Tim Deegan,
Ian Jackson, xen-devel, Samuel Thibault
>>> On 20.05.14 at 19:54, <mcgrof@suse.com> wrote:
> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
>> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
>> > --- a/config/StdGNU.mk
>> > +++ b/config/StdGNU.mk
>> > @@ -1,3 +1,17 @@
>> > +# These are standard defaults which you can use to avoid having
>> > +# to run ./configure -- you can use this to compile the hypervisor
>> > +# and the mini os:
>> > +#
>> > +# make xen
>> > +# sudo make -C xen install
>> > +#
>> > +# make -C extras/mini-os
>> > +include $(XEN_ROOT)/config/defaults.mk
>> > +
>> > +# This comes from running configure and will override
>> > +# the defaults.
>> > +-include $(XEN_ROOT)/config/Toplevel.mk
>>
>> So what is the result of running one of the above make invocations
>> without having run ./configure, then running ./configure before
>> running the same make invocation (for an incremental update)
>> again?
>
> In my last v4 you pointed out two targets which you wished to
> ensure would not require running configure, both of those targets:
>
> make xen -j $(getconf _NPROCESSORS_ONLN)
> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
>
> I have ensured this in this series and the above change indeed
> is what you were looking for.
I understand that; what I was asking however was what the effect
of the named sequence of operations would be, i.e. whether that
then perhaps would unexpectedly change things between the
original and the incremental make runs. Obviously an incremental
make should change _only_ things where the contributing sources
changed, but nothing resulting merely from the intermediate
./configure run.
>> > --- /dev/null
>> > +++ b/config/defaults.mk
>> > @@ -0,0 +1,21 @@
>> > +# Build system defaults, in case you never ran ./configure, this is
>> > +# supported to be able to build the xen hypervisor and the mini os:
>> > +#
>> > +# make xen
>> > +# sudo make -C xen install
>> > +#
>> > +# make -C extras/mini-os
>> > +PREFIX ?= /usr
>>
>> Presumably this is meant to retain the previous setting from
>> StdGNU.mk, but being tree-wide this then is kind of in conflict with
>> the tools default of /usr/local
>
> It would seem that way but ./configure is required to compile tools
> and /usr/local/ is actually preserved as the default for tools if no
> prefix is specifified, just as before.
I simply tried to point out an inconsistency that might be worth fixing
in the context of the re-work.
Jan
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 7:32 ` Jan Beulich
@ 2014-05-21 8:03 ` Luis R. Rodriguez
2014-05-21 8:11 ` Jan Beulich
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 8:03 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, Ian Campbell, Ian Jackson, Tim Deegan, xen-devel,
Samuel Thibault
On Wed, May 21, 2014 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 20.05.14 at 19:54, <mcgrof@suse.com> wrote:
>> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
>>> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
>>> > --- a/config/StdGNU.mk
>>> > +++ b/config/StdGNU.mk
>>> > @@ -1,3 +1,17 @@
>>> > +# These are standard defaults which you can use to avoid having
>>> > +# to run ./configure -- you can use this to compile the hypervisor
>>> > +# and the mini os:
>>> > +#
>>> > +# make xen
>>> > +# sudo make -C xen install
>>> > +#
>>> > +# make -C extras/mini-os
>>> > +include $(XEN_ROOT)/config/defaults.mk
>>> > +
>>> > +# This comes from running configure and will override
>>> > +# the defaults.
>>> > +-include $(XEN_ROOT)/config/Toplevel.mk
>>>
>>> So what is the result of running one of the above make invocations
>>> without having run ./configure, then running ./configure before
>>> running the same make invocation (for an incremental update)
>>> again?
>>
>> In my last v4 you pointed out two targets which you wished to
>> ensure would not require running configure, both of those targets:
>>
>> make xen -j $(getconf _NPROCESSORS_ONLN)
>> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
>>
>> I have ensured this in this series and the above change indeed
>> is what you were looking for.
>
> I understand that; what I was asking however was what the effect
> of the named sequence of operations would be, i.e. whether that
> then perhaps would unexpectedly change things between the
> original and the incremental make runs. Obviously an incremental
> make should change _only_ things where the contributing sources
> changed, but nothing resulting merely from the intermediate
> ./configure run.
Nothing I've introduced here should hamper the typical compile as what
you described you want. Let me know if you find issues though. We're
human.
>>> > --- /dev/null
>>> > +++ b/config/defaults.mk
>>> > @@ -0,0 +1,21 @@
>>> > +# Build system defaults, in case you never ran ./configure, this is
>>> > +# supported to be able to build the xen hypervisor and the mini os:
>>> > +#
>>> > +# make xen
>>> > +# sudo make -C xen install
>>> > +#
>>> > +# make -C extras/mini-os
>>> > +PREFIX ?= /usr
>>>
>>> Presumably this is meant to retain the previous setting from
>>> StdGNU.mk, but being tree-wide this then is kind of in conflict with
>>> the tools default of /usr/local
>>
>> It would seem that way but ./configure is required to compile tools
>> and /usr/local/ is actually preserved as the default for tools if no
>> prefix is specifified, just as before.
>
> I simply tried to point out an inconsistency that might be worth fixing
> in the context of the re-work.
I hear ya, just tired to preserve the old behavior which is where I
got those static non ./configure defaults. At this point from what
I've observed anything as small as a needle could affect anything
hugely in Xen so I would rather simplify the introduction of systemd
without radical changes, and let things evolve slowly as atomic
collateral evolutions over time where we could then bisect.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 8:03 ` Luis R. Rodriguez
@ 2014-05-21 8:11 ` Jan Beulich
2014-05-21 8:27 ` Luis R. Rodriguez
2014-05-21 10:33 ` Ian Campbell
0 siblings, 2 replies; 71+ messages in thread
From: Jan Beulich @ 2014-05-21 8:11 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Ian Campbell, Ian Jackson, Tim Deegan, xen-devel,
Samuel Thibault
>>> On 21.05.14 at 10:03, <mcgrof@suse.com> wrote:
> On Wed, May 21, 2014 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.05.14 at 19:54, <mcgrof@suse.com> wrote:
>>> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
>>>> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
>>>> > --- a/config/StdGNU.mk
>>>> > +++ b/config/StdGNU.mk
>>>> > @@ -1,3 +1,17 @@
>>>> > +# These are standard defaults which you can use to avoid having
>>>> > +# to run ./configure -- you can use this to compile the hypervisor
>>>> > +# and the mini os:
>>>> > +#
>>>> > +# make xen
>>>> > +# sudo make -C xen install
>>>> > +#
>>>> > +# make -C extras/mini-os
>>>> > +include $(XEN_ROOT)/config/defaults.mk
>>>> > +
>>>> > +# This comes from running configure and will override
>>>> > +# the defaults.
>>>> > +-include $(XEN_ROOT)/config/Toplevel.mk
>>>>
>>>> So what is the result of running one of the above make invocations
>>>> without having run ./configure, then running ./configure before
>>>> running the same make invocation (for an incremental update)
>>>> again?
>>>
>>> In my last v4 you pointed out two targets which you wished to
>>> ensure would not require running configure, both of those targets:
>>>
>>> make xen -j $(getconf _NPROCESSORS_ONLN)
>>> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
>>>
>>> I have ensured this in this series and the above change indeed
>>> is what you were looking for.
>>
>> I understand that; what I was asking however was what the effect
>> of the named sequence of operations would be, i.e. whether that
>> then perhaps would unexpectedly change things between the
>> original and the incremental make runs. Obviously an incremental
>> make should change _only_ things where the contributing sources
>> changed, but nothing resulting merely from the intermediate
>> ./configure run.
>
> Nothing I've introduced here should hamper the typical compile as what
> you described you want. Let me know if you find issues though. We're
> human.
Did you try it? I would expect the PREFIX change (from /usr to
/usr/local) alone would already alter things.
>>>> > --- /dev/null
>>>> > +++ b/config/defaults.mk
>>>> > @@ -0,0 +1,21 @@
>>>> > +# Build system defaults, in case you never ran ./configure, this is
>>>> > +# supported to be able to build the xen hypervisor and the mini os:
>>>> > +#
>>>> > +# make xen
>>>> > +# sudo make -C xen install
>>>> > +#
>>>> > +# make -C extras/mini-os
>>>> > +PREFIX ?= /usr
>>>>
>>>> Presumably this is meant to retain the previous setting from
>>>> StdGNU.mk, but being tree-wide this then is kind of in conflict with
>>>> the tools default of /usr/local
>>>
>>> It would seem that way but ./configure is required to compile tools
>>> and /usr/local/ is actually preserved as the default for tools if no
>>> prefix is specifified, just as before.
>>
>> I simply tried to point out an inconsistency that might be worth fixing
>> in the context of the re-work.
>
> I hear ya, just tired to preserve the old behavior which is where I
s/tired/tried/ perhaps? Or else I don't understand why you simply
changed it to /usr/local.
Jan
> got those static non ./configure defaults. At this point from what
> I've observed anything as small as a needle could affect anything
> hugely in Xen so I would rather simplify the introduction of systemd
> without radical changes, and let things evolve slowly as atomic
> collateral evolutions over time where we could then bisect.
>
> Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 8:11 ` Jan Beulich
@ 2014-05-21 8:27 ` Luis R. Rodriguez
2014-05-21 10:33 ` Ian Campbell
1 sibling, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 8:27 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, Ian Campbell, Ian Jackson, Tim Deegan, xen-devel,
Samuel Thibault
[-- Attachment #1.1: Type: text/plain, Size: 4341 bytes --]
On May 21, 2014 1:13 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 21.05.14 at 10:03, <mcgrof@suse.com> wrote:
> > On Wed, May 21, 2014 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 20.05.14 at 19:54, <mcgrof@suse.com> wrote:
> >>> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
> >>>> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
> >>>> > --- a/config/StdGNU.mk
> >>>> > +++ b/config/StdGNU.mk
> >>>> > @@ -1,3 +1,17 @@
> >>>> > +# These are standard defaults which you can use to avoid having
> >>>> > +# to run ./configure -- you can use this to compile the hypervisor
> >>>> > +# and the mini os:
> >>>> > +#
> >>>> > +# make xen
> >>>> > +# sudo make -C xen install
> >>>> > +#
> >>>> > +# make -C extras/mini-os
> >>>> > +include $(XEN_ROOT)/config/defaults.mk
> >>>> > +
> >>>> > +# This comes from running configure and will override
> >>>> > +# the defaults.
> >>>> > +-include $(XEN_ROOT)/config/Toplevel.mk
> >>>>
> >>>> So what is the result of running one of the above make invocations
> >>>> without having run ./configure, then running ./configure before
> >>>> running the same make invocation (for an incremental update)
> >>>> again?
> >>>
> >>> In my last v4 you pointed out two targets which you wished to
> >>> ensure would not require running configure, both of those targets:
> >>>
> >>> make xen -j $(getconf _NPROCESSORS_ONLN)
> >>> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
> >>>
> >>> I have ensured this in this series and the above change indeed
> >>> is what you were looking for.
> >>
> >> I understand that; what I was asking however was what the effect
> >> of the named sequence of operations would be, i.e. whether that
> >> then perhaps would unexpectedly change things between the
> >> original and the incremental make runs. Obviously an incremental
> >> make should change _only_ things where the contributing sources
> >> changed, but nothing resulting merely from the intermediate
> >> ./configure run.
> >
> > Nothing I've introduced here should hamper the typical compile as what
> > you described you want. Let me know if you find issues though. We're
> > human.
>
> Did you try it?
Tried only full install with cxenstored, oxenstored on both old init and
systemd with and without systemd lib dev libs, with and without ocaml poo.
I also tried to compile test what you asked, anything else I haven't tried
so test results, reports and patches at this point are welcomed for all the
other cases.
> I would expect the PREFIX change (from /usr to
> /usr/local) alone would already alter things.
That's only done upon configure, but maybe I'm missing something.
> >>>> > --- /dev/null
> >>>> > +++ b/config/defaults.mk
> >>>> > @@ -0,0 +1,21 @@
> >>>> > +# Build system defaults, in case you never ran ./configure, this
is
> >>>> > +# supported to be able to build the xen hypervisor and the mini
os:
> >>>> > +#
> >>>> > +# make xen
> >>>> > +# sudo make -C xen install
> >>>> > +#
> >>>> > +# make -C extras/mini-os
> >>>> > +PREFIX ?= /usr
> >>>>
> >>>> Presumably this is meant to retain the previous setting from
> >>>> StdGNU.mk, but being tree-wide this then is kind of in conflict with
> >>>> the tools default of /usr/local
> >>>
> >>> It would seem that way but ./configure is required to compile tools
> >>> and /usr/local/ is actually preserved as the default for tools if no
> >>> prefix is specifified, just as before.
> >>
> >> I simply tried to point out an inconsistency that might be worth fixing
> >> in the context of the re-work.
> >
> > I hear ya, just tired to preserve the old behavior which is where I
>
> s/tired/tried/ perhaps?
Tried. Which is what I tried.
> Or else I don't understand why you simply
> changed it to /usr/local.
That's the tools default upon default configure.
Luis
> Jan
>
> > got those static non ./configure defaults. At this point from what
> > I've observed anything as small as a needle could affect anything
> > hugely in Xen so I would rather simplify the introduction of systemd
> > without radical changes, and let things evolve slowly as atomic
> > collateral evolutions over time where we could then bisect.
> >
> > Luis
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 6502 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 8:11 ` Jan Beulich
2014-05-21 8:27 ` Luis R. Rodriguez
@ 2014-05-21 10:33 ` Ian Campbell
2014-05-21 13:54 ` Jan Beulich
2014-05-21 15:14 ` Ian Campbell
1 sibling, 2 replies; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 10:33 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, Tim Deegan, Luis R. Rodriguez, Ian Jackson,
xen-devel, Samuel Thibault
On Wed, 2014-05-21 at 09:11 +0100, Jan Beulich wrote:
> >>> On 21.05.14 at 10:03, <mcgrof@suse.com> wrote:
> > On Wed, May 21, 2014 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >>>>> On 20.05.14 at 19:54, <mcgrof@suse.com> wrote:
> >>> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
> >>>> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
> >>>> > --- a/config/StdGNU.mk
> >>>> > +++ b/config/StdGNU.mk
> >>>> > @@ -1,3 +1,17 @@
> >>>> > +# These are standard defaults which you can use to avoid having
> >>>> > +# to run ./configure -- you can use this to compile the hypervisor
> >>>> > +# and the mini os:
> >>>> > +#
> >>>> > +# make xen
> >>>> > +# sudo make -C xen install
> >>>> > +#
> >>>> > +# make -C extras/mini-os
> >>>> > +include $(XEN_ROOT)/config/defaults.mk
> >>>> > +
> >>>> > +# This comes from running configure and will override
> >>>> > +# the defaults.
> >>>> > +-include $(XEN_ROOT)/config/Toplevel.mk
> >>>>
> >>>> So what is the result of running one of the above make invocations
> >>>> without having run ./configure, then running ./configure before
> >>>> running the same make invocation (for an incremental update)
> >>>> again?
> >>>
> >>> In my last v4 you pointed out two targets which you wished to
> >>> ensure would not require running configure, both of those targets:
> >>>
> >>> make xen -j $(getconf _NPROCESSORS_ONLN)
> >>> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
> >>>
> >>> I have ensured this in this series and the above change indeed
> >>> is what you were looking for.
> >>
> >> I understand that; what I was asking however was what the effect
> >> of the named sequence of operations would be, i.e. whether that
> >> then perhaps would unexpectedly change things between the
> >> original and the incremental make runs. Obviously an incremental
> >> make should change _only_ things where the contributing sources
> >> changed, but nothing resulting merely from the intermediate
> >> ./configure run.
> >
> > Nothing I've introduced here should hamper the typical compile as what
> > you described you want. Let me know if you find issues though. We're
> > human.
>
> Did you try it? I would expect the PREFIX change (from /usr to
> /usr/local) alone would already alter things.
Do either the xen or extras/mini-os subtrees depend on PREFIX at all?
At most I would expoect xen to depend on BOOT_DIR which I don't think is
overridable with configure?
I haven't looked at this patch in detail yet but I'm not sure why
Toplevel.mk is getting included in the StdGNU.mk rather than including
it from FOO.mk only for those components which depend on configure
having been run.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 10:33 ` Ian Campbell
@ 2014-05-21 13:54 ` Jan Beulich
2014-05-21 15:14 ` Ian Campbell
1 sibling, 0 replies; 71+ messages in thread
From: Jan Beulich @ 2014-05-21 13:54 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Tim Deegan, Luis Rodriguez, Ian Jackson, xen-devel,
Samuel Thibault
>>> On 21.05.14 at 12:33, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-05-21 at 09:11 +0100, Jan Beulich wrote:
>> >>> On 21.05.14 at 10:03, <mcgrof@suse.com> wrote:
>> > On Wed, May 21, 2014 at 12:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >>>>> On 20.05.14 at 19:54, <mcgrof@suse.com> wrote:
>> >>> On Tue, May 20, 2014 at 07:37:53AM -0600, Jan Beulich wrote:
>> >>>> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
>> >>>> > --- a/config/StdGNU.mk
>> >>>> > +++ b/config/StdGNU.mk
>> >>>> > @@ -1,3 +1,17 @@
>> >>>> > +# These are standard defaults which you can use to avoid having
>> >>>> > +# to run ./configure -- you can use this to compile the hypervisor
>> >>>> > +# and the mini os:
>> >>>> > +#
>> >>>> > +# make xen
>> >>>> > +# sudo make -C xen install
>> >>>> > +#
>> >>>> > +# make -C extras/mini-os
>> >>>> > +include $(XEN_ROOT)/config/defaults.mk
>> >>>> > +
>> >>>> > +# This comes from running configure and will override
>> >>>> > +# the defaults.
>> >>>> > +-include $(XEN_ROOT)/config/Toplevel.mk
>> >>>>
>> >>>> So what is the result of running one of the above make invocations
>> >>>> without having run ./configure, then running ./configure before
>> >>>> running the same make invocation (for an incremental update)
>> >>>> again?
>> >>>
>> >>> In my last v4 you pointed out two targets which you wished to
>> >>> ensure would not require running configure, both of those targets:
>> >>>
>> >>> make xen -j $(getconf _NPROCESSORS_ONLN)
>> >>> make -C extras/mini-os -j $(getconf _NPROCESSORS_ONLN)
>> >>>
>> >>> I have ensured this in this series and the above change indeed
>> >>> is what you were looking for.
>> >>
>> >> I understand that; what I was asking however was what the effect
>> >> of the named sequence of operations would be, i.e. whether that
>> >> then perhaps would unexpectedly change things between the
>> >> original and the incremental make runs. Obviously an incremental
>> >> make should change _only_ things where the contributing sources
>> >> changed, but nothing resulting merely from the intermediate
>> >> ./configure run.
>> >
>> > Nothing I've introduced here should hamper the typical compile as what
>> > you described you want. Let me know if you find issues though. We're
>> > human.
>>
>> Did you try it? I would expect the PREFIX change (from /usr to
>> /usr/local) alone would already alter things.
>
> Do either the xen or extras/mini-os subtrees depend on PREFIX at all?
>
> At most I would expoect xen to depend on BOOT_DIR which I don't think is
> overridable with configure?
I would have expected the /usr use in x86_64.mk to have got
converted to $(PREFIX), but looks like it's still hard coded. With
that there indeed shouldn't be any use of PREFIX in those sub-trees.
Jan
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 10:33 ` Ian Campbell
2014-05-21 13:54 ` Jan Beulich
@ 2014-05-21 15:14 ` Ian Campbell
2014-05-21 15:20 ` Jan Beulich
1 sibling, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 15:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, Ian Jackson, Luis R. Rodriguez, Tim Deegan,
xen-devel, Samuel Thibault
On Wed, 2014-05-21 at 11:33 +0100, Ian Campbell wrote:
> I haven't looked at this patch in detail yet but I'm not sure why
> Toplevel.mk is getting included in the StdGNU.mk rather than including
> it from FOO.mk only for those components which depend on configure
> having been run.
So, having looked at this patch now it seems to me that the stuff being
added to config/Toplevel.mk should instead be added to a new
config/Paths.mk which should be included from the appropriate
per-subsystem config/{Tools,Stubdom,Docs}.mk and not from anything which
would cause it to be included when building Xen or minios.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 15:14 ` Ian Campbell
@ 2014-05-21 15:20 ` Jan Beulich
0 siblings, 0 replies; 71+ messages in thread
From: Jan Beulich @ 2014-05-21 15:20 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Tim Deegan, Luis Rodriguez, Ian Jackson, xen-devel,
Samuel Thibault
>>> On 21.05.14 at 17:14, <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-05-21 at 11:33 +0100, Ian Campbell wrote:
>> I haven't looked at this patch in detail yet but I'm not sure why
>> Toplevel.mk is getting included in the StdGNU.mk rather than including
>> it from FOO.mk only for those components which depend on configure
>> having been run.
>
> So, having looked at this patch now it seems to me that the stuff being
> added to config/Toplevel.mk should instead be added to a new
> config/Paths.mk which should be included from the appropriate
> per-subsystem config/{Tools,Stubdom,Docs}.mk and not from anything which
> would cause it to be included when building Xen or minios.
Yes, that seems desirable.
Jan
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-20 12:31 ` [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place Luis R. Rodriguez
2014-05-20 13:37 ` Jan Beulich
[not found] ` <537B76D1020000780001422C@suse.com>
@ 2014-05-21 15:26 ` Ian Campbell
2014-05-21 21:54 ` Luis R. Rodriguez
2 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 15:26 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Tim Deegan, Luis R. Rodriguez, Ian Jackson,
Jan Beulich, Samuel Thibault, xen-devel
On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> diff --git a/README b/README
> index 9bbe734..079e6a9 100644
> --- a/README
> +++ b/README
> @@ -129,6 +129,22 @@ performed with root privileges.]
> versions of those scripts, so that you can copy the dist directory
> to another machine and install from that distribution.
>
> +Xen system configuration
> +========================
> +
> +Xen uses a set of variables for system configuration and upon build time,
s/upon/at/
> +because of this these variables are defined on a top level general input
> +source and are generated after running ./configure. There are two versions
> +of the input files, one for scripts (bash, python) and another for C / header
> +files:
> +
> + * config/xen-environment-header.in - used to generate config/xen-environment-header
> + * config/xen-environment-scripts.in - used to generate config/xen-environment-scripts
> +
> +Further documentation can be found on the wiki:
This all seems very developer focused (why would users care about
this?). I think most of this would be better as a comment in the
relevant files.
> +
> +http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
This might be useful if it were more user focused in particular if it
referred to the installed locations of things and not the source which
users don't care about.
> +
> Python Runtime Libraries
> ========================
>
> diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> index c6439f6..273f1e8 100644
> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -1,3 +1,17 @@
> +# These are standard defaults which you can use to avoid having
> +# to run ./configure -- you can use this to compile the hypervisor
> +# and the mini os:
> +#
> +# make xen
> +# sudo make -C xen install
> +#
> +# make -C extras/mini-os
> +include $(XEN_ROOT)/config/defaults.mk
> +
> +# This comes from running configure and will override
> +# the defaults.
> +-include $(XEN_ROOT)/config/Toplevel.mk
As I said in the reply to the subthread started by Jan I don't think any
of this belongs here.
> new file mode 100644
> index 0000000..7dd7a53
> --- /dev/null
> +++ b/config/xen-environment-header.in
> @@ -0,0 +1,13 @@
> +#define SBINDIR "@SBINDIR@"
> +#define BINDIR "@BINDIR@"
> +#define LIBEXEC "@LIBEXEC@"
> +#define LIBDIR "@LIBDIR@"
> +#define SHAREDIR "@SHAREDIR@"
> +
> +#define PRIVATE_BINDIR "@PRIVATE_BINDIR@"
> +#define XENFIRMWAREDIR "@XENFIRMWAREDIR@"
> +#define XEN_CONFIG_DIR "@XEN_CONFIG_DIR@"
> +#define XEN_SCRIPT_DIR "@XEN_SCRIPT_DIR@"
> +#define XEN_LOCK_DIR "@XEN_LOCK_DIR@"
> +#define XEN_RUN_DIR "@XEN_RUN_DIR@"
> +#define XEN_PAGING_DIR "@XEN_PAGING_DIR@"
> diff --git a/config/xen-environment-scripts.in b/config/xen-environment-scripts.in
> new file mode 100644
> index 0000000..9623231
> --- /dev/null
> +++ b/config/xen-environment-scripts.in
> @@ -0,0 +1,15 @@
> +SBINDIR="@SBINDIR@"
> +BINDIR="@BINDIR@"
> +LIBEXEC="@LIBEXEC@"
> +LIBDIR="@LIBDIR@"
> +SHAREDIR="@SHAREDIR@"
> +
> +PRIVATE_BINDIR="@PRIVATE_BINDIR@"
> +XENFIRMWAREDIR="@XENFIRMWAREDIR@"
> +XEN_CONFIG_DIR="@XEN_CONFIG_DIR@"
> +XEN_SCRIPT_DIR="@XEN_SCRIPT_DIR@"
> +XEN_LOCK_DIR="@XEN_LOCK_DIR@"
> +XEN_LOG_DIR="@XEN_LOG_DIR@"
> +XEN_LIB_STORED="@XEN_LIB_STORED@"
> +XEN_RUN_DIR="@XEN_RUN_DIR@"
> +XEN_PAGING_DIR="@XEN_PAGING_DIR@"
The downside of these is that we now need to keep both in sync. I think
a reasonable compromise would be to generate the scripts version of this
via autoconf and create the C version using a mechanism similar to the
existing buildmakevars2file etc stuff.
> diff --git a/m4/expand_config.m4 b/m4/expand_config.m4
expand_config is a strange name for this, paths.m4 would be more
descriptive, wouldn't it?
Or this sort of thing wouldn't be out of place in confgure.ac I think.
> new file mode 100644
> index 0000000..717fcd1
> --- /dev/null
> +++ b/m4/expand_config.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)
TBH I thought that after going through all this fuss --bindir and
--sbindir might worl.
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index c41de27..f0f624a 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -48,18 +48,19 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
>
> TARGETS=$(STUBDOM_TARGETS)
>
> +STUBDOMPATH="stubdompath.sh"
> +
> +$(STUBDOMPATH): $(XEN_ROOT)/config/xen-environment-scripts
> + @cp $(XEN_ROOT)/config/xen-environment-scripts $@
cp $< $@
Not sure it needs hiding from the user either.
(there are a few of these)
> diff --git a/stubdom/configure.ac b/stubdom/configure.ac
> index 6468203..d6b0fbf 100644
> --- a/stubdom/configure.ac
> +++ b/stubdom/configure.ac
> @@ -16,6 +16,9 @@ m4_include([../m4/features.m4])
> m4_include([../m4/path_or_fail.m4])
> m4_include([../m4/depends.m4])
> m4_include([../m4/fetcher.m4])
> +m4_include([../m4/expand_config.m4])
> +
> +AX_XEN_EXPAND_CONFIG()
Doesn't only the toplevel configure.ac need this, because you've put the
things into config/Toplevel.mk (soon to be config/Paths.mk).
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 15:26 ` Ian Campbell
@ 2014-05-21 21:54 ` Luis R. Rodriguez
2014-05-22 9:46 ` Ian Campbell
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 21:54 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Luis R. Rodriguez, Tim Deegan, Ian Jackson,
Jan Beulich, Samuel Thibault, xen-devel
On Wed, May 21, 2014 at 04:26:33PM +0100, Ian Campbell wrote:
> On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > diff --git a/README b/README
> > index 9bbe734..079e6a9 100644
> > --- a/README
> > +++ b/README
> > @@ -129,6 +129,22 @@ performed with root privileges.]
> > versions of those scripts, so that you can copy the dist directory
> > to another machine and install from that distribution.
> >
> > +Xen system configuration
> > +========================
> > +
> > +Xen uses a set of variables for system configuration and upon build time,
>
> s/upon/at/
Ammended.
> > +because of this these variables are defined on a top level general input
> > +source and are generated after running ./configure. There are two versions
> > +of the input files, one for scripts (bash, python) and another for C / header
> > +files:
> > +
> > + * config/xen-environment-header.in - used to generate config/xen-environment-header
> > + * config/xen-environment-scripts.in - used to generate config/xen-environment-scripts
> > +
> > +Further documentation can be found on the wiki:
>
> This all seems very developer focused (why would users care about
> this?). I think most of this would be better as a comment in the
> relevant files.
>
> > +
> > +http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
>
> This might be useful if it were more user focused in particular if it
> referred to the installed locations of things and not the source which
> users don't care about.
OK tossed it into config/xen-environment-scripts.in.
> > +
> > Python Runtime Libraries
> > ========================
> >
> > diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> > index c6439f6..273f1e8 100644
> > --- a/config/StdGNU.mk
> > +++ b/config/StdGNU.mk
> > @@ -1,3 +1,17 @@
> > +# These are standard defaults which you can use to avoid having
> > +# to run ./configure -- you can use this to compile the hypervisor
> > +# and the mini os:
> > +#
> > +# make xen
> > +# sudo make -C xen install
> > +#
> > +# make -C extras/mini-os
> > +include $(XEN_ROOT)/config/defaults.mk
> > +
> > +# This comes from running configure and will override
> > +# the defaults.
> > +-include $(XEN_ROOT)/config/Toplevel.mk
>
> As I said in the reply to the subthread started by Jan I don't think any
> of this belongs here.
OK.
> > new file mode 100644
> > index 0000000..7dd7a53
> > --- /dev/null
> > +++ b/config/xen-environment-header.in
> > @@ -0,0 +1,13 @@
> > +#define SBINDIR "@SBINDIR@"
> > +#define BINDIR "@BINDIR@"
> > +#define LIBEXEC "@LIBEXEC@"
> > +#define LIBDIR "@LIBDIR@"
> > +#define SHAREDIR "@SHAREDIR@"
> > +
> > +#define PRIVATE_BINDIR "@PRIVATE_BINDIR@"
> > +#define XENFIRMWAREDIR "@XENFIRMWAREDIR@"
> > +#define XEN_CONFIG_DIR "@XEN_CONFIG_DIR@"
> > +#define XEN_SCRIPT_DIR "@XEN_SCRIPT_DIR@"
> > +#define XEN_LOCK_DIR "@XEN_LOCK_DIR@"
> > +#define XEN_RUN_DIR "@XEN_RUN_DIR@"
> > +#define XEN_PAGING_DIR "@XEN_PAGING_DIR@"
> > diff --git a/config/xen-environment-scripts.in b/config/xen-environment-scripts.in
> > new file mode 100644
> > index 0000000..9623231
> > --- /dev/null
> > +++ b/config/xen-environment-scripts.in
> > @@ -0,0 +1,15 @@
> > +SBINDIR="@SBINDIR@"
> > +BINDIR="@BINDIR@"
> > +LIBEXEC="@LIBEXEC@"
> > +LIBDIR="@LIBDIR@"
> > +SHAREDIR="@SHAREDIR@"
> > +
> > +PRIVATE_BINDIR="@PRIVATE_BINDIR@"
> > +XENFIRMWAREDIR="@XENFIRMWAREDIR@"
> > +XEN_CONFIG_DIR="@XEN_CONFIG_DIR@"
> > +XEN_SCRIPT_DIR="@XEN_SCRIPT_DIR@"
> > +XEN_LOCK_DIR="@XEN_LOCK_DIR@"
> > +XEN_LOG_DIR="@XEN_LOG_DIR@"
> > +XEN_LIB_STORED="@XEN_LIB_STORED@"
> > +XEN_RUN_DIR="@XEN_RUN_DIR@"
> > +XEN_PAGING_DIR="@XEN_PAGING_DIR@"
>
> The downside of these is that we now need to keep both in sync. I think
> a reasonable compromise would be to generate the scripts version of this
> via autoconf and create the C version using a mechanism similar to the
> existing buildmakevars2file etc stuff.
OK I kept only config/xen-environment-scripts.in and repurposed
buildmakevars2file for C header generation.
> > diff --git a/m4/expand_config.m4 b/m4/expand_config.m4
>
> expand_config is a strange name for this, paths.m4 would be more
> descriptive, wouldn't it?
Sure.
> Or this sort of thing wouldn't be out of place in confgure.ac I think.
More on this below.
> > new file mode 100644
> > index 0000000..717fcd1
> > --- /dev/null
> > +++ b/m4/expand_config.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)
>
> TBH I thought that after going through all this fuss --bindir and
> --sbindir might worl.
We can surely do that but that is an atomic change and I'd much prefer
this was treated separately as a separate patch given that this would
change existing behavior. If you want me to roll this in I can do so
but do not think that's a good idea for regression analysis.
> > diff --git a/stubdom/Makefile b/stubdom/Makefile
> > index c41de27..f0f624a 100644
> > --- a/stubdom/Makefile
> > +++ b/stubdom/Makefile
> > @@ -48,18 +48,19 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
> >
> > TARGETS=$(STUBDOM_TARGETS)
> >
> > +STUBDOMPATH="stubdompath.sh"
> > +
> > +$(STUBDOMPATH): $(XEN_ROOT)/config/xen-environment-scripts
> > + @cp $(XEN_ROOT)/config/xen-environment-scripts $@
>
> cp $< $@
>
> Not sure it needs hiding from the user either.
>
> (there are a few of these)
OK.
> > diff --git a/stubdom/configure.ac b/stubdom/configure.ac
> > index 6468203..d6b0fbf 100644
> > --- a/stubdom/configure.ac
> > +++ b/stubdom/configure.ac
> > @@ -16,6 +16,9 @@ m4_include([../m4/features.m4])
> > m4_include([../m4/path_or_fail.m4])
> > m4_include([../m4/depends.m4])
> > m4_include([../m4/fetcher.m4])
> > +m4_include([../m4/expand_config.m4])
> > +
> > +AX_XEN_EXPAND_CONFIG()
>
> Doesn't only the toplevel configure.ac need this, because you've put the
> things into config/Toplevel.mk (soon to be config/Paths.mk).
I had similar expectations and was equally surprised to see this didn't fly.
Here's the latest version of the patch let me know what you folks think,
I think its pointless to foll in a new series just to address this rather
more important change.
From: "Luis R. Rodriguez" <mcgrof@suse.com>
Date: Mon, 28 Apr 2014 03:52:29 -0700
Subject: [PATCH] autoconf: xen: move standard path variables to
config/Paths.mk.in
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 replaces all that with a *one* central file script file,
and lets us generate the C header file from the first one. To do
this we repuropose buildmakevars2file Makefile helper to generate
the header file.
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 | 3 ++
Config.mk | 9 +++++-
Makefile | 18 +++++++++++-
config/Paths.mk.in | 23 +++++++++++++++
config/Stubdom.mk.in | 1 +
config/xen-environment-scripts.in | 35 ++++++++++++++++++++++
configure.ac | 9 +++++-
m4/paths.m4 | 61 +++++++++++++++++++++++++++++++++++++++
stubdom/Makefile | 18 +++++++-----
stubdom/configure.ac | 3 ++
tools/Rules.mk | 1 +
tools/configure.ac | 3 ++
tools/hotplug/common/Makefile | 6 ++--
tools/libxl/Makefile | 11 ++-----
tools/python/Makefile | 6 ++--
15 files changed, 182 insertions(+), 25 deletions(-)
create mode 100644 config/Paths.mk.in
create mode 100644 config/xen-environment-scripts.in
create mode 100644 m4/paths.m4
diff --git a/.gitignore b/.gitignore
index 562c262..4792070 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,9 @@ config.log
config.status
config.cache
config/Toplevel.mk
+config/Paths.mk
+config/xen-environment-scripts
+config/xen-environment-header
build-*
dist/*
diff --git a/Config.mk b/Config.mk
index 6a93533..6580e47 100644
--- a/Config.mk
+++ b/Config.mk
@@ -175,10 +175,17 @@ define buildmakevars2file-closure
SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR \
XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
XEN_RUN_DIR XEN_PAGING_DIR, \
- echo "$(var)=\"$($(var))\"" >>$(1).tmp;) \
+ echo "#define $(var) \"$($(var))\"" >>$(1).tmp;) \
$(call move-if-changed,$(1).tmp,$(1))
endef
+empty_genpath = $(eval $(call empty_genpath-closure))
+define empty_genpath-closure
+ .PHONY: genpath-skip
+ genpath-skip:
+ @# do nothing
+endef
+
ifeq ($(debug_symbols),y)
CFLAGS += -g
endif
diff --git a/Makefile b/Makefile
index 41dabbf..fa3427e 100644
--- a/Makefile
+++ b/Makefile
@@ -39,10 +39,26 @@ endif
test:
$(MAKE) -C tools/python test
+XEN_ENV_HEADER="$(XEN_ROOT)/config/xen-environment-header"
+CONFIG_RUN="$(XEN_ROOT)/config.status"
+
+genpath-target = $(call buildmakevars2file,$(XEN_ENV_HEADER))
+$(eval $(genpath-target))
+
+genpath-ignore = $(call empty_genpath)
+$(eval $(genpath-ignore))
+
+# This generates xen-environment-header only if configure has been run
+ifneq ("$(wildcard $(CONFIG_RUN))","")
+ XENGENPATH=genpath-skip
+else
+ XENGENPATH=genpath
+endif
+
# build and install everything into local dist directory
.PHONY: dist
dist: DESTDIR=$(DISTDIR)/install
-dist: $(TARGS_DIST) dist-misc
+dist: $(XENGENPATH) $(TARGS_DIST) dist-misc
dist-misc:
$(INSTALL_DIR) $(DISTDIR)/
diff --git a/config/Paths.mk.in b/config/Paths.mk.in
new file mode 100644
index 0000000..4f22960
--- /dev/null
+++ b/config/Paths.mk.in
@@ -0,0 +1,23 @@
+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/config/xen-environment-scripts.in b/config/xen-environment-scripts.in
new file mode 100644
index 0000000..06913f8
--- /dev/null
+++ b/config/xen-environment-scripts.in
@@ -0,0 +1,35 @@
+# Xen system configuration
+# ========================
+#
+# Xen uses a set of variables for system configuration and at build time,
+# because of this these variables are defined one master input source file
+# and is generated after running ./configure. The master source is located
+# on the xen source tree at under config/xen-environment-scripts.in and it
+# is used to generate config/xen-environment-scripts after ./configure has
+# been run. The C header file is generated after make is run. There are two
+# files the build system can then use, one for scripts (bash, python) and
+# another for C / header files:
+#
+# * config/xen-environment-scripts
+# * config/xen-environment-header
+#
+# These files may be used by the build system to generate local copies
+# for their own purpose. 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@"
+LIBDIR="@LIBDIR@"
+SHAREDIR="@SHAREDIR@"
+
+PRIVATE_BINDIR="@PRIVATE_BINDIR@"
+XENFIRMWAREDIR="@XENFIRMWAREDIR@"
+XEN_CONFIG_DIR="@XEN_CONFIG_DIR@"
+XEN_SCRIPT_DIR="@XEN_SCRIPT_DIR@"
+XEN_LOCK_DIR="@XEN_LOCK_DIR@"
+XEN_LOG_DIR="@XEN_LOG_DIR@"
+XEN_LIB_STORED="@XEN_LIB_STORED@"
+XEN_RUN_DIR="@XEN_RUN_DIR@"
+XEN_PAGING_DIR="@XEN_PAGING_DIR@"
diff --git a/configure.ac b/configure.ac
index 6c14524..96c6e75 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,12 +5,19 @@ 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
+ config/xen-environment-scripts
+])
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/stubdom/Makefile b/stubdom/Makefile
index c41de27..147848f 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -7,6 +7,7 @@ export stubdom=y
export debug=y
include $(XEN_ROOT)/Config.mk
-include $(XEN_ROOT)/config/Stubdom.mk
+include $(XEN_ROOT)/config/Paths.mk
GNU_TARGET_ARCH:=$(XEN_TARGET_ARCH)
ifeq ($(XEN_TARGET_ARCH),x86_32)
@@ -48,18 +49,19 @@ TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
TARGETS=$(STUBDOM_TARGETS)
+STUBDOMPATH="stubdompath.sh"
+
+$(STUBDOMPATH): $(XEN_ROOT)/config/xen-environment-scripts
+ cp $(XEN_ROOT)/config/xen-environment-scripts $@
+
.PHONY: all
all: build
ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath $(STUBDOM_BUILD)
+build: $(STUBDOMPATH) $(STUBDOM_BUILD)
else
-build: genpath
+build: $(STUBDOMPATH)
endif
-STUBDOMPATH="stubdompath.sh"
-genpath-target = $(call buildmakevars2file,$(STUBDOMPATH))
-$(eval $(genpath-target))
-
##############
# Cross-newlib
##############
@@ -448,9 +450,9 @@ xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
#########
ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme $(STUBDOM_INSTALL)
+install: $(STUBDOMPATH) install-readme $(STUBDOM_INSTALL)
else
-install: genpath
+install: $(STUBDOMPATH)
endif
install-readme:
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index 6468203..f1bea4c 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -16,6 +16,9 @@ m4_include([../m4/features.m4])
m4_include([../m4/path_or_fail.m4])
m4_include([../m4/depends.m4])
m4_include([../m4/fetcher.m4])
+m4_include([../m4/paths.m4])
+
+AX_XEN_EXPAND_CONFIG()
# Enable/disable stub domains
AX_STUBDOM_CONDITIONAL([ioemu-stubdom], [ioemu])
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 13d8fc1..423f2b1 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
diff --git a/tools/configure.ac b/tools/configure.ac
index 25d7ca3..05b2f4f 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -47,6 +47,9 @@ 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])
+
+AX_XEN_EXPAND_CONFIG()
# Enable/disable options
AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
diff --git a/tools/hotplug/common/Makefile b/tools/hotplug/common/Makefile
index 18d87aa..3afc6d5 100644
--- a/tools/hotplug/common/Makefile
+++ b/tools/hotplug/common/Makefile
@@ -9,14 +9,14 @@ HOTPLUGPATH="hotplugpath.sh"
XEN_SCRIPTS =
XEN_SCRIPT_DATA = $(HOTPLUGPATH)
-genpath-target = $(call buildmakevars2file,$(HOTPLUGPATH))
-$(eval $(genpath-target))
+$(HOTPLUGPATH): $(XEN_ROOT)/config/xen-environment-scripts
+ cp $(XEN_ROOT)/config/xen-environment-scripts $@
.PHONY: all
all: build
.PHONY: build
-build: genpath
+build: $(HOTPLUGPATH)
.PHONY: install
install: all install-scripts
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4cfa275..fedfd62 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -97,6 +97,9 @@ TEST_PROGS += $(foreach t, $(LIBXL_TESTS),test_$t)
$(LIBXL_OBJS) $(LIBXL_TEST_OBJS): CFLAGS += $(CFLAGS_LIBXL) -include $(XEN_ROOT)/tools/config.h
+_paths.h: $(XEN_ROOT)/config/xen-environment-header
+ @cp $(XEN_ROOT)/config/xen-environment-header $@
+
AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h _paths.h \
libxlu_disk_l.h _libxl_save_msgs_callout.h _libxl_save_msgs_helper.h
AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
@@ -141,9 +144,6 @@ $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS) $(SAVE_HELPER_OBJS) \
@rm -f $*.[ch]
$(FLEX) --header-file=$*.h --outfile=$*.c $<
-genpath-target = $(call buildmakevars2file,_paths.h.tmp)
-$(eval $(genpath-target))
-
libxl.api-ok: check-libxl-api-rules _libxl.api-for-check
$(PERL) $^
touch $@
@@ -154,11 +154,6 @@ _%.api-for-check: %.h $(AUTOINCS)
>$@.new
mv -f $@.new $@
-_paths.h: genpath
- sed -e "s/\([^=]*\)=\(.*\)/#define \1 \2/g" $@.tmp >$@.2.tmp
- rm -f $@.tmp
- $(call move-if-changed,$@.2.tmp,$@)
-
_libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
$(PERL) $^ --prefix=libxl >$@.new
$(call move-if-changed,$@.new,$@)
diff --git a/tools/python/Makefile b/tools/python/Makefile
index c433cbe..b1887e0 100644
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -6,11 +6,11 @@ all: build
XENPATH = "xen/util/path.py"
-genpath-target = $(call buildmakevars2file,$(XENPATH))
-$(eval $(genpath-target))
+$(XENPATH): $(XEN_ROOT)/config/xen-environment-scripts
+ cp $(XEN_ROOT)/config/xen-environment-scripts $@
.PHONY: build
-build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
+build: $(XENPATH) genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
$(XEN_ROOT)/tools/libxl/idl.py
PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
$(XEN_ROOT)/tools/libxl/libxl_types.idl \
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place
2014-05-21 21:54 ` Luis R. Rodriguez
@ 2014-05-22 9:46 ` Ian Campbell
0 siblings, 0 replies; 71+ messages in thread
From: Ian Campbell @ 2014-05-22 9:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Luis R. Rodriguez, Tim Deegan, Ian Jackson,
Jan Beulich, Samuel Thibault, xen-devel
On Wed, 2014-05-21 at 23:54 +0200, Luis R. Rodriguez wrote:
> > > new file mode 100644
> > > index 0000000..717fcd1
> > > --- /dev/null
> > > +++ b/m4/expand_config.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)
> >
> > TBH I thought that after going through all this fuss --bindir and
> > --sbindir might worl.
>
> We can surely do that but that is an atomic change and I'd much prefer
> this was treated separately as a separate patch given that this would
> change existing behavior. If you want me to roll this in I can do so
> but do not think that's a good idea for regression analysis.
Fair enough, if you feel like doing a followup that would be fine, or
else we can leave it for now.
> > > diff --git a/stubdom/configure.ac b/stubdom/configure.ac
> > > index 6468203..d6b0fbf 100644
> > > --- a/stubdom/configure.ac
> > > +++ b/stubdom/configure.ac
> > > @@ -16,6 +16,9 @@ m4_include([../m4/features.m4])
> > > m4_include([../m4/path_or_fail.m4])
> > > m4_include([../m4/depends.m4])
> > > m4_include([../m4/fetcher.m4])
> > > +m4_include([../m4/expand_config.m4])
> > > +
> > > +AX_XEN_EXPAND_CONFIG()
> >
> > Doesn't only the toplevel configure.ac need this, because you've put the
> > things into config/Toplevel.mk (soon to be config/Paths.mk).
>
> I had similar expectations and was equally surprised to see this didn't fly.
Possibly this will go away with moving things to config/Path.mk instead
of Toplevel.mk?
>
> Here's the latest version of the patch let me know what you folks think,
It's much better, thanks. Still some comments though.
> diff --git a/Config.mk b/Config.mk
> index 6a93533..6580e47 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -175,10 +175,17 @@ define buildmakevars2file-closure
You should probably rename the function, both to make it match the new
behaviour and to root out all the existing uses.
> SBINDIR BINDIR LIBEXEC LIBDIR SHAREDIR PRIVATE_BINDIR \
> XENFIRMWAREDIR XEN_CONFIG_DIR XEN_SCRIPT_DIR XEN_LOCK_DIR \
> XEN_RUN_DIR XEN_PAGING_DIR, \
> - echo "$(var)=\"$($(var))\"" >>$(1).tmp;) \
> + echo "#define $(var) \"$($(var))\"" >>$(1).tmp;) \
> $(call move-if-changed,$(1).tmp,$(1))
> endef
>
> +empty_genpath = $(eval $(call empty_genpath-closure))
> +define empty_genpath-closure
> + .PHONY: genpath-skip
> + genpath-skip:
> + @# do nothing
> +endef
What is this for?
> +
> ifeq ($(debug_symbols),y)
> CFLAGS += -g
> endif
> diff --git a/Makefile b/Makefile
> index 41dabbf..fa3427e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -39,10 +39,26 @@ endif
> test:
> $(MAKE) -C tools/python test
>
> +XEN_ENV_HEADER="$(XEN_ROOT)/config/xen-environment-header"
> +CONFIG_RUN="$(XEN_ROOT)/config.status"
> +
> +genpath-target = $(call buildmakevars2file,$(XEN_ENV_HEADER))
> +$(eval $(genpath-target))
I intended for you to use this in each of the submakefiles which needs
it rather than at the toplevel, to avoid interactions with the xen and
mini-os subtrees. Is there some particular reason to put them here?
> diff --git a/config/xen-environment-scripts.in b/config/xen-environment-scripts.in
> new file mode 100644
> index 0000000..06913f8
> --- /dev/null
> +++ b/config/xen-environment-scripts.in
This appears to be completely duplicating Paths.mk.
> +m4_include([../m4/paths.m4])
> +
> +AX_XEN_EXPAND_CONFIG()
I think with your latest changes you should try again removing these
from all the sub-configures. If it doesn't work please show the error
and we'll see if we can figure something out.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (10 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 11/14] autoconf: xen: move standard variables to a generic place Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-21 15:44 ` Ian Campbell
2014-05-20 12:31 ` [PATCH v5 13/14] xencommons: move module list into a generic place Luis R. Rodriguez
2014-05-20 12:31 ` [PATCH v5 14/14] systemd: add xen systemd service and module files Luis R. Rodriguez
13 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Keir Fraser, Ian Campbell, Tim Deegan, Luis R. Rodriguez,
Ian Jackson, Jan Beulich
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=cxenstored
./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 we can move it to the shared top level config and use
this to simplify both the legacy init script and eventually our systemd
service files. This should also make it clear on how you can still
enable usage of cxenstored but still also use ocaml tools. If you have
both oxenstored and cxenstored installed you can change the xenstore by
a simple flip on the system configuration file.
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.
[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>
---
Please run ./autgen.sh after this patch is applied.
README | 34 +++++++++++++++++++
config/Toplevel.mk.in | 3 ++
| 3 ++
config/xen-environment-scripts.in | 3 ++
configure.ac | 1 +
m4/expand_config.m4 | 61 +++++++++++++++++++++++++++++++++++
stubdom/configure.ac | 1 +
tools/hotplug/Linux/init.d/xencommons | 6 ----
8 files changed, 106 insertions(+), 6 deletions(-)
diff --git a/README b/README
index 079e6a9..4183b34 100644
--- a/README
+++ b/README
@@ -145,6 +145,40 @@ Further documentation can be found on the wiki:
http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
+xenstored: cxenstored and oxenstored
+====================================
+
+Xen uses a xenstore [0] to upkeep configuration and status information shared
+between domains. A daemon is provided to help respond to queries from dom0
+and guests, details for the xenstored can be found on the wiki's xenstored [2]
+page. Two xenstored daemons are supported and you can choose which xenstored
+you want to enable on a system through configure:
+
+ ./configure --with-xenstored=cxenstored
+ ./configure --with-xenstored=oxenstored
+
+By defalut oxenstored will be used if the ocaml development tools are found.
+If you enable oxenstored the cxenstored will still be built and installed,
+the xenstored used can be changed through the configuration file:
+
+/etc/xen/scripts/hotplugpath.sh
+
+This file has two relevant variables which are specific to the version of
+xenstored used:
+
+ * XENSTORED - specifies the full path of the xenstored binary
+ * XENSTORE - specifies the name of the xenstored binary
+
+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. The original /etc/xen/scripts/hotplugpath.sh is sourced
+from the general xen system configuration file documented above, which is
+generated at build time after running ./configure.
+
+[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/config/Toplevel.mk.in b/config/Toplevel.mk.in
index fc2754c..bea9d96 100644
--- a/config/Toplevel.mk.in
+++ b/config/Toplevel.mk.in
@@ -23,3 +23,6 @@ XENFIRMWAREDIR := @XENFIRMWAREDIR@
XEN_CONFIG_DIR := @XEN_CONFIG_DIR@
XEN_SCRIPT_DIR := @XEN_SCRIPT_DIR@
+
+XENSTORED := @XENSTORED@
+XENSTORE := @XENSTORE@
--git a/config/xen-environment-header.in b/config/xen-environment-header.in
index 7dd7a53..3ee8e32 100644
--- a/config/xen-environment-header.in
+++ b/config/xen-environment-header.in
@@ -11,3 +11,6 @@
#define XEN_LOCK_DIR "@XEN_LOCK_DIR@"
#define XEN_RUN_DIR "@XEN_RUN_DIR@"
#define XEN_PAGING_DIR "@XEN_PAGING_DIR@"
+
+#define XENSTORED @XENSTORED@
+#define XENSTORE @XENSTORE@
diff --git a/config/xen-environment-scripts.in b/config/xen-environment-scripts.in
index 9623231..a17e0e9 100644
--- a/config/xen-environment-scripts.in
+++ b/config/xen-environment-scripts.in
@@ -13,3 +13,6 @@ XEN_LOG_DIR="@XEN_LOG_DIR@"
XEN_LIB_STORED="@XEN_LIB_STORED@"
XEN_RUN_DIR="@XEN_RUN_DIR@"
XEN_PAGING_DIR="@XEN_PAGING_DIR@"
+
+XENSTORED="@XENSTORED@"
+XENSTORE="@XENSTORE@"
diff --git a/configure.ac b/configure.ac
index 3f26a39..f5faa4f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -16,6 +16,7 @@ AC_CANONICAL_HOST
m4_include([m4/features.m4])
m4_include([m4/subsystem.m4])
m4_include([m4/expand_config.m4])
+m4_include([m4/ocaml.m4])
AX_XEN_EXPAND_CONFIG()
diff --git a/m4/expand_config.m4 b/m4/expand_config.m4
index 717fcd1..40d9707 100644
--- a/m4/expand_config.m4
+++ b/m4/expand_config.m4
@@ -58,4 +58,65 @@ AC_SUBST(XEN_RUN_DIR)
XEN_PAGING_DIR=/var/lib/xen/xenpaging
AC_SUBST(XEN_PAGING_DIR)
+
+AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
+ AC_PROG_OCAML
+ AC_PROG_FINDLIB
+ AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
+ 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
+ AC_PROG_OCAML
+ AC_PROG_FINDLIB
+ AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
+ xenstore="cxenstored"
+ xenstored=$SBINDIR/xenstored
+ ])
+])
+
+AS_IF([test "x$XENSTORE" = "x"], [
+AC_ARG_WITH([xenstored],
+ AS_HELP_STRING([--with-xenstored@<:@=cxenstored|cxenstored@:>@],
+ [This lets you choose which xenstore daemon you want, you have
+ two options: the original xenstored written in C (cxenstored)
+ 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" = "xcxenstored"], [
+ xenstore="cxenstored"
+ xenstored=$SBINDIR/xenstored
+ ])
+ AS_IF([test "x$withval" = "xoxenstored"], [
+ xenstore="oxenstored"
+ xenstored=$SBINDIR/oxenstored
+ AX_XEN_OCAML_XENSTORE_CHECK()
+ ])
+ AS_IF([test "x$withval" != "xoxenstored" && test "x$withval" != "xcxenstored"], [
+ AC_MSG_ERROR([Unsupported xenstored specified, supported types: oxenstored cxenstored])
+ ])
+ ],
+ [
+ AX_XEN_OCAML_XENSTORE_DEFAULTS()
+ ])
+])
+
+XENSTORE=$xenstore
+AC_SUBST(XENSTORE)
+
+AS_IF([test "x$XENSTORED" = "x"], [
+ XENSTORED=$xenstored
+])
+AC_SUBST(XENSTORED)
+
+AS_IF([test "x$XENSTORE" != "xcxenstored" && test "x$XENSTORE" != "xoxenstored"],
+ [AC_MSG_ERROR([Invalid xenstore: $XENSTORE])])
])
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index d6b0fbf..3c30004 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -17,6 +17,7 @@ m4_include([../m4/path_or_fail.m4])
m4_include([../m4/depends.m4])
m4_include([../m4/fetcher.m4])
m4_include([../m4/expand_config.m4])
+m4_include([../m4/ocaml.m4])
AX_XEN_EXPAND_CONFIG()
diff --git a/tools/hotplug/Linux/init.d/xencommons b/tools/hotplug/Linux/init.d/xencommons
index 4ebd636..2bb6f26 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -83,12 +83,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.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-20 12:31 ` [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference Luis R. Rodriguez
@ 2014-05-21 15:44 ` Ian Campbell
2014-05-21 23:02 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-21 15:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Tim Deegan, Luis R. Rodriguez, Ian Jackson,
Jan Beulich, xen-devel
On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> 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=cxenstored
> ./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 we can move it to the shared top level config and use
> this to simplify both the legacy init script and eventually our systemd
> service files. This should also make it clear on how you can still
> enable usage of cxenstored but still also use ocaml tools. If you have
> both oxenstored and cxenstored installed you can change the xenstore by
> a simple flip on the system configuration file.
>
> 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.
>
> [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>
> ---
>
> Please run ./autgen.sh after this patch is applied.
>
> README | 34 +++++++++++++++++++
> config/Toplevel.mk.in | 3 ++
> config/xen-environment-header.in | 3 ++
> config/xen-environment-scripts.in | 3 ++
> configure.ac | 1 +
> m4/expand_config.m4 | 61 +++++++++++++++++++++++++++++++++++
> stubdom/configure.ac | 1 +
> tools/hotplug/Linux/init.d/xencommons | 6 ----
> 8 files changed, 106 insertions(+), 6 deletions(-)
>
> diff --git a/README b/README
> index 079e6a9..4183b34 100644
> --- a/README
> +++ b/README
> @@ -145,6 +145,40 @@ Further documentation can be found on the wiki:
>
> http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
>
> +xenstored: cxenstored and oxenstored
> +====================================
> +
> +Xen uses a xenstore [0] to upkeep configuration and status information shared
s/a xenstore/xenstore/
or uses a configuration database (xenstore[0]).
"upkeep" is not the word you are looking for either. ...to store... is
probably correct, or maintain.
> +between domains. A daemon is provided to help respond to queries from dom0
> +and guests,
Well, the daemon is provided because it is the thing which implemented
the xenstore. Saying it is provided to respond to queries is a strange
way to phrase it.
> details for the xenstored can be found on the wiki's xenstored [2]
> +page. Two xenstored daemons are supported and you can choose which xenstored
> +you want to enable on a system through configure:
^ by default (I hope, it should be possible to
change my mind by editing the configuration without rebuilding)
> +
> + ./configure --with-xenstored=cxenstored
> + ./configure --with-xenstored=oxenstored
> +
> +By defalut oxenstored will be used if the ocaml development tools are found.
"default"
> +If you enable oxenstored the cxenstored will still be built and installed,
> +the xenstored used can be changed through the configuration file:
> +
> +/etc/xen/scripts/hotplugpath.sh
That's an unconventional place for such a configuration. Today it is
in /etc/{sysconfig,default}/xencommons, I think, which is more expected
IMHO. That comes from tools/hotplug/Linux/init.d/sysconfig.xencommons.
It might be reasonable for hotplugpath.sh to define
XENSTORE_xenstored=/path/to/xenstored
XENSTORE_oxenstored=/path/to/oxenstored
and use the existing XENSTORED variable in sysconfig to select which.
This would also avoid the user having to update the name and the path
(as would the use of basename mind you)
> diff --git a/m4/expand_config.m4 b/m4/expand_config.m4
> index 717fcd1..40d9707 100644
> --- a/m4/expand_config.m4
> +++ b/m4/expand_config.m4
> @@ -58,4 +58,65 @@ AC_SUBST(XEN_RUN_DIR)
>
I'd say that most of this belongs in something which is handled from
tools/configure.ac not the top level. m4/xenstored.m4 seems logical.
> XEN_PAGING_DIR=/var/lib/xen/xenpaging
> AC_SUBST(XEN_PAGING_DIR)
> +
> +AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
> + AC_PROG_OCAML
> + AC_PROG_FINDLIB
> + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
THen you could rely on m4/ocaml.m4 to have checked all this already.
> + 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], [
Why is this separate from CHECK? Also there can't be any need to call
AC_PROG_{OCAML,FINDLIB} quite as many times as you do, surely.
> + xenstore="oxenstored"
> + xenstored=$SBINDIR/oxenstored
> + AC_PROG_OCAML
> + AC_PROG_FINDLIB
> + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
> + xenstore="cxenstored"
> + xenstored=$SBINDIR/xenstored
> + ])
> +])
> +
> +AS_IF([test "x$XENSTORE" = "x"], [
> +AC_ARG_WITH([xenstored],
> + AS_HELP_STRING([--with-xenstored@<:@=cxenstored|cxenstored@:>@],
> + [This lets you choose which xenstore daemon you want, you have
> + two options: the original xenstored written in C (cxenstored)
> + 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]),
Does this not end up with an overly verbose configure --help output?
> + [
> + AS_IF([test "x$withval" = "xcxenstored"], [
> + xenstore="cxenstored"
> + xenstored=$SBINDIR/xenstored
> + ])
> + AS_IF([test "x$withval" = "xoxenstored"], [
> + xenstore="oxenstored"
> + xenstored=$SBINDIR/oxenstored
> + AX_XEN_OCAML_XENSTORE_CHECK()
> + ])
xenstore=$withval
if $xenstore = ocaml && ocaml not detected ;
AC_ERROR[].
fi
> + AS_IF([test "x$withval" != "xoxenstored" && test "x$withval" != "xcxenstored"], [
> + AC_MSG_ERROR([Unsupported xenstored specified, supported types: oxenstored cxenstored])
> + ])
> + ],
> + [
> + AX_XEN_OCAML_XENSTORE_DEFAULTS()
> + ])
> +])
> +
> +XENSTORE=$xenstore
> +AC_SUBST(XENSTORE)
> +
> +AS_IF([test "x$XENSTORED" = "x"], [
> + XENSTORED=$xenstored
> +])
> +AC_SUBST(XENSTORED)
> +
> +AS_IF([test "x$XENSTORE" != "xcxenstored" && test "x$XENSTORE" != "xoxenstored"],
> + [AC_MSG_ERROR([Invalid xenstore: $XENSTORE])])
Didn't this already get checked above?
> ])
Ian
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-21 15:44 ` Ian Campbell
@ 2014-05-21 23:02 ` Luis R. Rodriguez
2014-05-22 10:05 ` Ian Campbell
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-21 23:02 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Luis R. Rodriguez, Ian Jackson, Tim Deegan,
Jan Beulich, xen-devel
On Wed, May 21, 2014 at 04:44:00PM +0100, Ian Campbell wrote:
> On Tue, 2014-05-20 at 05:31 -0700, Luis R. Rodriguez wrote:
> > diff --git a/README b/README
> > index 079e6a9..4183b34 100644
> > --- a/README
> > +++ b/README
>
> > +If you enable oxenstored the cxenstored will still be built and installed,
> > +the xenstored used can be changed through the configuration file:
> > +
> > +/etc/xen/scripts/hotplugpath.sh
>
> That's an unconventional place for such a configuration. Today it is
> in /etc/{sysconfig,default}/xencommons, I think, which is more expected
> IMHO. That comes from tools/hotplug/Linux/init.d/sysconfig.xencommons.
Yeah good point, I had not seen that.
> It might be reasonable for hotplugpath.sh to define
> XENSTORE_xenstored=/path/to/xenstored
> XENSTORE_oxenstored=/path/to/oxenstored
>
> and use the existing XENSTORED variable in sysconfig to select which.
Ah but but hotplugpath.sh is one of those automatically generated files
and after my last patch in this series they are all now shared in one
master file, config/xen-environment-scripts.in, and since the we want
to keep script file Shell / Python agnostic checking which one is set
on sysconfig is not something reasonable to do on that master file.
So here's the thing:
My series of patches already deals with the old init and xencommons script to
start xenstore, it used the hotplugpath.sh for deducing the xenstore
daemon it should use by default and switching this to rely on the sysconfig
xencommons should be easy if it wasn't already dealt with there already.
For systemd though we can't use varibles on ExecStart for the process, we
however can use environment variables. We have a few options. Fedora's
approach was to use two service unit files which conflicted with each other,
although I'm sure we can work it out by using a target unit and let folks
flip it seems rather silly to me to maintain two service unit files with
identical entries. Therefore in my new approach usres would have to manually
edit the service file with the differnt path / binary. Another possibility
is to have a central launcher binary that just does getenv() and execve()
on the desired binary. If this is agreeable I can work on it and it could
even be shared by the old init as well.
> This would also avoid the user having to update the name and the path
> (as would the use of basename mind you)
Agreed.
> > diff --git a/m4/expand_config.m4 b/m4/expand_config.m4
> > index 717fcd1..40d9707 100644
> > --- a/m4/expand_config.m4
> > +++ b/m4/expand_config.m4
> > @@ -58,4 +58,65 @@ AC_SUBST(XEN_RUN_DIR)
> >
>
> I'd say that most of this belongs in something which is handled from
> tools/configure.ac not the top level. m4/xenstored.m4 seems logical.
Sure.
> > XEN_PAGING_DIR=/var/lib/xen/xenpaging
> > AC_SUBST(XEN_PAGING_DIR)
> > +
> > +AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
> > + AC_PROG_OCAML
> > + AC_PROG_FINDLIB
> > + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
>
> THen you could rely on m4/ocaml.m4 to have checked all this already.
Just including m4/ocaml.m4 won't get us much, the above logic assumes
that file was included so there is a bit of a trick we need to adjust
in order to avoid multiple calls to the same checks.
>
> > + 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], [
>
> Why is this separate from CHECK?
Its not a check, I should remove the double calls to AC_PROG_OCAML
and AC_PROG_OCAML, what this does is it sets the defaults based
on your build system without considering any flags passed.
> Also there can't be any need to call
> AC_PROG_{OCAML,FINDLIB} quite as many times as you do, surely.
We can surely move the AC_PROG_OCAML and AC_PROG_FINDLIB calls outside
so that the check can be done just once. We want to support not having
to pass the flag for specifying the xenstore preference.
> > + xenstore="oxenstored"
> > + xenstored=$SBINDIR/oxenstored
> > + AC_PROG_OCAML
> > + AC_PROG_FINDLIB
> > + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
> > + xenstore="cxenstored"
> > + xenstored=$SBINDIR/xenstored
> > + ])
> > +])
> > +
> > +AS_IF([test "x$XENSTORE" = "x"], [
> > +AC_ARG_WITH([xenstored],
> > + AS_HELP_STRING([--with-xenstored@<:@=cxenstored|cxenstored@:>@],
> > + [This lets you choose which xenstore daemon you want, you have
> > + two options: the original xenstored written in C (cxenstored)
> > + 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]),
>
> Does this not end up with an overly verbose configure --help output?
Its fine by me, check and let me know if its too much.
> > + [
> > + AS_IF([test "x$withval" = "xcxenstored"], [
> > + xenstore="cxenstored"
> > + xenstored=$SBINDIR/xenstored
> > + ])
> > + AS_IF([test "x$withval" = "xoxenstored"], [
> > + xenstore="oxenstored"
> > + xenstored=$SBINDIR/oxenstored
> > + AX_XEN_OCAML_XENSTORE_CHECK()
> > + ])
>
> xenstore=$withval
OK
> if $xenstore = ocaml && ocaml not detected ;
> AC_ERROR[].
> fi
That's what AX_XEN_OCAML_XENSTORE_CHECK() does, but I agree this
can be simplified. Will work on that.
>
> > + AS_IF([test "x$withval" != "xoxenstored" && test "x$withval" != "xcxenstored"], [
> > + AC_MSG_ERROR([Unsupported xenstored specified, supported types: oxenstored cxenstored])
> > + ])
> > + ],
> > + [
> > + AX_XEN_OCAML_XENSTORE_DEFAULTS()
> > + ])
> > +])
> > +
> > +XENSTORE=$xenstore
> > +AC_SUBST(XENSTORE)
> > +
> > +AS_IF([test "x$XENSTORED" = "x"], [
> > + XENSTORED=$xenstored
> > +])
> > +AC_SUBST(XENSTORED)
> > +
> > +AS_IF([test "x$XENSTORE" != "xcxenstored" && test "x$XENSTORE" != "xoxenstored"],
> > + [AC_MSG_ERROR([Invalid xenstore: $XENSTORE])])
>
> Didn't this already get checked above?
Yeah I went trigger happy with checks, will remove.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-21 23:02 ` Luis R. Rodriguez
@ 2014-05-22 10:05 ` Ian Campbell
2014-05-23 23:20 ` Luis R. Rodriguez
0 siblings, 1 reply; 71+ messages in thread
From: Ian Campbell @ 2014-05-22 10:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Luis R. Rodriguez, Ian Jackson, Tim Deegan,
Jan Beulich, xen-devel
On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > It might be reasonable for hotplugpath.sh to define
> > XENSTORE_xenstored=/path/to/xenstored
> > XENSTORE_oxenstored=/path/to/oxenstored
> >
> > and use the existing XENSTORED variable in sysconfig to select which.
>
> Ah but but hotplugpath.sh is one of those automatically generated files
> and after my last patch in this series they are all now shared in one
> master file, config/xen-environment-scripts.in, and since the we want
> to keep script file Shell / Python agnostic checking which one is set
> on sysconfig is not something reasonable to do on that master file.
Well, it must be possible to change which xenstored implementation is
used by editing a single setting in /etc/{sysconfig,default}/xencommons,
maybe that means more code somewhere, I don't know. idieally you would
be able to say
XENSTORE=xenstored # C xenstore at default path
XENSTORE=oxenstored # Ocaml xenstore at default path
XENSTORE=/path/to/something # xenstored at some custom path.
> My series of patches already deals with the old init and xencommons script to
> start xenstore, it used the hotplugpath.sh for deducing the xenstore
> daemon it should use by default and switching this to rely on the sysconfig
> xencommons should be easy if it wasn't already dealt with there already.
>
> For systemd though we can't use varibles on ExecStart for the process, we
> however can use environment variables. We have a few options. Fedora's
> approach was to use two service unit files which conflicted with each other,
> although I'm sure we can work it out by using a target unit and let folks
> flip it seems rather silly to me to maintain two service unit files with
> identical entries. Therefore in my new approach usres would have to manually
> edit the service file with the differnt path / binary. Another possibility
> is to have a central launcher binary that just does getenv() and execve()
> on the desired binary. If this is agreeable I can work on it and it could
> even be shared by the old init as well.
Which is considered the most "systemd" approach?
> > > XEN_PAGING_DIR=/var/lib/xen/xenpaging
> > > AC_SUBST(XEN_PAGING_DIR)
> > > +
> > > +AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
> > > + AC_PROG_OCAML
> > > + AC_PROG_FINDLIB
> > > + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
> >
> > THen you could rely on m4/ocaml.m4 to have checked all this already.
>
> Just including m4/ocaml.m4 won't get us much, the above logic assumes
> that file was included so there is a bit of a trick we need to adjust
> in order to avoid multiple calls to the same checks.
If you do/call these checks in tools/configure.ac then I think you can
just arrange to sequence things correctly with the ocaml ones by the
ordering in the file.
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-22 10:05 ` Ian Campbell
@ 2014-05-23 23:20 ` Luis R. Rodriguez
2014-05-28 9:30 ` Ian Campbell
0 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-23 23:20 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Luis R. Rodriguez, Ian Jackson, Tim Deegan,
Jan Beulich, xen-devel
On Thu, May 22, 2014 at 11:05:47AM +0100, Ian Campbell wrote:
> On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > > It might be reasonable for hotplugpath.sh to define
> > > XENSTORE_xenstored=/path/to/xenstored
> > > XENSTORE_oxenstored=/path/to/oxenstored
> > >
> > > and use the existing XENSTORED variable in sysconfig to select which.
> >
> > Ah but but hotplugpath.sh is one of those automatically generated files
> > and after my last patch in this series they are all now shared in one
> > master file, config/xen-environment-scripts.in, and since the we want
> > to keep script file Shell / Python agnostic checking which one is set
> > on sysconfig is not something reasonable to do on that master file.
>
> Well, it must be possible to change which xenstored implementation is
> used by editing a single setting in /etc/{sysconfig,default}/xencommons,
> maybe that means more code somewhere, I don't know. idieally you would
> be able to say
> XENSTORE=xenstored # C xenstore at default path
> XENSTORE=oxenstored # Ocaml xenstore at default path
> XENSTORE=/path/to/something # xenstored at some custom path.
Agreed.
> > My series of patches already deals with the old init and xencommons script to
> > start xenstore, it used the hotplugpath.sh for deducing the xenstore
> > daemon it should use by default and switching this to rely on the sysconfig
> > xencommons should be easy if it wasn't already dealt with there already.
> >
> > For systemd though we can't use varibles on ExecStart for the process, we
> > however can use environment variables. We have a few options. Fedora's
> > approach was to use two service unit files which conflicted with each other,
> > although I'm sure we can work it out by using a target unit and let folks
> > flip it seems rather silly to me to maintain two service unit files with
> > identical entries. Therefore in my new approach usres would have to manually
> > edit the service file with the differnt path / binary. Another possibility
> > is to have a central launcher binary that just does getenv() and execve()
> > on the desired binary. If this is agreeable I can work on it and it could
> > even be shared by the old init as well.
>
> Which is considered the most "systemd" approach?
Systemd tries to even recommend to shy away from sysconfig/default directory for
stashing entries, one can set environment variables within the service unit itself,
but if we are to maintain compatiblity with old stuff relying on sysconfig seems
the reasonable and accepted way, then we'd include that file as part of the
running environment, just as our systemd service unit files do now in this series.
More details here:
http://0pointer.de/blog/projects/on-etc-sysinit.html
As for dynamic use daemons, there aren't good examples but the undocumented way
of doing this but as a per a conversation at the LF Linux Collaboration summit
one way to deal with this is to use one service target files for defining what
we do, we'd have two separate service unit files for each cxenstored and
oxenstored, the services that need to depend on it would depend on the target,
not the actual service unit files, the user then would have to enable one or
the other. A sysconfig edit however would not trigger a change, which is what
we seem to want, and the only reasonable and *clean* way I can think of
supporting this on systemd is through a launcher which does getenv() and
execve(). If we do that we could rename The C version of xenstored to cxenstored
leave oxenstored as is and have the launcher eat up the xenstored name.
I've poked systemd-devel for more advice:
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019427.html
Unfortunatley no one has provided further input than what I got at LF collaboration
summit. One thought that occurs to me is to have systemd deal with these types of
situations a launcher of its own, but that's work and perhaps something to consider
for the future. The one thing that concerns me about the sysconfig/default variable
reliance is that its not ideally what we what but hey -- I don't think we can seek
for perfection right now, only a good start.
A launcher is my own preferred way to deal with this, provided I haven't gotten
more input let me know all your folks thought on this. I'll also poke internally
at SUSE for more thoughts.
> > > > XEN_PAGING_DIR=/var/lib/xen/xenpaging
> > > > AC_SUBST(XEN_PAGING_DIR)
> > > > +
> > > > +AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
> > > > + AC_PROG_OCAML
> > > > + AC_PROG_FINDLIB
> > > > + AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
> > >
> > > THen you could rely on m4/ocaml.m4 to have checked all this already.
> >
> > Just including m4/ocaml.m4 won't get us much, the above logic assumes
> > that file was included so there is a bit of a trick we need to adjust
> > in order to avoid multiple calls to the same checks.
>
> If you do/call these checks in tools/configure.ac then I think you can
> just arrange to sequence things correctly with the ocaml ones by the
> ordering in the file.
OK.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-23 23:20 ` Luis R. Rodriguez
@ 2014-05-28 9:30 ` Ian Campbell
2014-05-29 16:09 ` Don Koch
` (2 more replies)
0 siblings, 3 replies; 71+ messages in thread
From: Ian Campbell @ 2014-05-28 9:30 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Keir Fraser, Luis R. Rodriguez, Ian Jackson, Tim Deegan,
Jan Beulich, xen-devel
On Sat, 2014-05-24 at 01:20 +0200, Luis R. Rodriguez wrote:
> On Thu, May 22, 2014 at 11:05:47AM +0100, Ian Campbell wrote:
> > On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > > > It might be reasonable for hotplugpath.sh to define
> > > > XENSTORE_xenstored=/path/to/xenstored
> > > > XENSTORE_oxenstored=/path/to/oxenstored
> > > >
> > > > and use the existing XENSTORED variable in sysconfig to select which.
> > >
> > > Ah but but hotplugpath.sh is one of those automatically generated files
> > > and after my last patch in this series they are all now shared in one
> > > master file, config/xen-environment-scripts.in, and since the we want
> > > to keep script file Shell / Python agnostic checking which one is set
> > > on sysconfig is not something reasonable to do on that master file.
> >
> > Well, it must be possible to change which xenstored implementation is
> > used by editing a single setting in /etc/{sysconfig,default}/xencommons,
> > maybe that means more code somewhere, I don't know. idieally you would
> > be able to say
> > XENSTORE=xenstored # C xenstore at default path
> > XENSTORE=oxenstored # Ocaml xenstore at default path
> > XENSTORE=/path/to/something # xenstored at some custom path.
>
> Agreed.
>
> > > My series of patches already deals with the old init and xencommons script to
> > > start xenstore, it used the hotplugpath.sh for deducing the xenstore
> > > daemon it should use by default and switching this to rely on the sysconfig
> > > xencommons should be easy if it wasn't already dealt with there already.
> > >
> > > For systemd though we can't use varibles on ExecStart for the process, we
> > > however can use environment variables. We have a few options. Fedora's
> > > approach was to use two service unit files which conflicted with each other,
> > > although I'm sure we can work it out by using a target unit and let folks
> > > flip it seems rather silly to me to maintain two service unit files with
> > > identical entries. Therefore in my new approach usres would have to manually
> > > edit the service file with the differnt path / binary. Another possibility
> > > is to have a central launcher binary that just does getenv() and execve()
> > > on the desired binary. If this is agreeable I can work on it and it could
> > > even be shared by the old init as well.
> >
> > Which is considered the most "systemd" approach?
>
> Systemd tries to even recommend to shy away from sysconfig/default directory for
> stashing entries, one can set environment variables within the service unit itself,
> but if we are to maintain compatiblity with old stuff relying on sysconfig seems
> the reasonable and accepted way, then we'd include that file as part of the
> running environment, just as our systemd service unit files do now in this series.
I'm mostly concerned that people *not* using systemd can continue to
use /etc/{default,sysconfig}/xencommons in the way which they are used
to.
For people who are using systemd the question is whether it is more or
less confusing to have an unused /etc/{default,sysconfig}/xencommons
sitting there vs. doing things in the less "systemd" way. The compromise
is perhaps to seed the defaults from /e/{d,s}/xencommons but allow them
to be changed in either that file or in the unit file? Is that possible?
>
> More details here:
>
> http://0pointer.de/blog/projects/on-etc-sysinit.html
>
> As for dynamic use daemons, there aren't good examples but the undocumented way
> of doing this but as a per a conversation at the LF Linux Collaboration summit
> one way to deal with this is to use one service target files for defining what
> we do, we'd have two separate service unit files for each cxenstored and
> oxenstored, the services that need to depend on it would depend on the target,
> not the actual service unit files, the user then would have to enable one or
> the other. A sysconfig edit however would not trigger a change, which is what
> we seem to want,
What do you mean? I don't expect editing sysconfig will automagically do
anything, some further action would be required, and since xenstored is
involved that further action most likely involves a reboot.
Can a systemd unit "soft fail"? i.e. fail but not make a huge red
highlighted fuss about it? Then each of the two units could check if
they were configured and softfail if not (expecting that the other one
is configured). Alternatively perhaps there is some sort of pre-check
hook which could be used to see if the unit can/should be run?
Ian.
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-28 9:30 ` Ian Campbell
@ 2014-05-29 16:09 ` Don Koch
2014-05-29 23:29 ` Luis R. Rodriguez
2014-05-29 23:29 ` Luis R. Rodriguez
2 siblings, 0 replies; 71+ messages in thread
From: Don Koch @ 2014-05-29 16:09 UTC (permalink / raw)
To: Ian Campbell
Cc: Keir Fraser, Luis R. Rodriguez, Tim Deegan, Luis R. Rodriguez,
Ian Jackson, Jan Beulich, xen-devel
On Wed, 28 May 2014 10:30:49 +0100
Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Sat, 2014-05-24 at 01:20 +0200, Luis R. Rodriguez wrote:
> > On Thu, May 22, 2014 at 11:05:47AM +0100, Ian Campbell wrote:
> > > On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > > > > It might be reasonable for hotplugpath.sh to define
> > > > > XENSTORE_xenstored=/path/to/xenstored
> > > > > XENSTORE_oxenstored=/path/to/oxenstored
> > > > >
> > > > > and use the existing XENSTORED variable in sysconfig to select which.
> > > >
> > > > Ah but but hotplugpath.sh is one of those automatically generated files
> > > > and after my last patch in this series they are all now shared in one
> > > > master file, config/xen-environment-scripts.in, and since the we want
> > > > to keep script file Shell / Python agnostic checking which one is set
> > > > on sysconfig is not something reasonable to do on that master file.
> > >
> > > Well, it must be possible to change which xenstored implementation is
> > > used by editing a single setting in /etc/{sysconfig,default}/xencommons,
> > > maybe that means more code somewhere, I don't know. idieally you would
> > > be able to say
> > > XENSTORE=xenstored # C xenstore at default path
> > > XENSTORE=oxenstored # Ocaml xenstore at default path
> > > XENSTORE=/path/to/something # xenstored at some custom path.
> >
> > Agreed.
> >
> > > > My series of patches already deals with the old init and xencommons script to
> > > > start xenstore, it used the hotplugpath.sh for deducing the xenstore
> > > > daemon it should use by default and switching this to rely on the sysconfig
> > > > xencommons should be easy if it wasn't already dealt with there already.
> > > >
> > > > For systemd though we can't use varibles on ExecStart for the process, we
> > > > however can use environment variables. We have a few options. Fedora's
> > > > approach was to use two service unit files which conflicted with each other,
> > > > although I'm sure we can work it out by using a target unit and let folks
> > > > flip it seems rather silly to me to maintain two service unit files with
> > > > identical entries. Therefore in my new approach usres would have to manually
> > > > edit the service file with the differnt path / binary. Another possibility
> > > > is to have a central launcher binary that just does getenv() and execve()
> > > > on the desired binary. If this is agreeable I can work on it and it could
> > > > even be shared by the old init as well.
> > >
> > > Which is considered the most "systemd" approach?
> >
> > Systemd tries to even recommend to shy away from sysconfig/default directory for
> > stashing entries, one can set environment variables within the service unit itself,
> > but if we are to maintain compatiblity with old stuff relying on sysconfig seems
> > the reasonable and accepted way, then we'd include that file as part of the
> > running environment, just as our systemd service unit files do now in this series.
>
> I'm mostly concerned that people *not* using systemd can continue to
> use /etc/{default,sysconfig}/xencommons in the way which they are used
> to.
>
> For people who are using systemd the question is whether it is more or
> less confusing to have an unused /etc/{default,sysconfig}/xencommons
> sitting there vs. doing things in the less "systemd" way. The compromise
> is perhaps to seed the defaults from /e/{d,s}/xencommons but allow them
> to be changed in either that file or in the unit file? Is that possible?
How about moving xencommons into /etc/xen and, optionally, making a
link to it from /etc/{default,sysconfig} as the distro warrants? That
way we have a consistent place to find it and the user still finds it
where they're used to finding it.
-d
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-28 9:30 ` Ian Campbell
2014-05-29 16:09 ` Don Koch
@ 2014-05-29 23:29 ` Luis R. Rodriguez
2014-06-01 6:15 ` [systemd-devel] " Lennart Poettering
2014-06-01 6:15 ` Lennart Poettering
2014-05-29 23:29 ` Luis R. Rodriguez
2 siblings, 2 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-29 23:29 UTC (permalink / raw)
To: Ian Campbell, luto
Cc: Luis R. Rodriguez, xen-devel, systemd-devel, Ian Jackson,
Jan Beulich, Keir Fraser, Tim Deegan, linux-kernel, ebiederm,
morgan, linux-security-module
[-- Attachment #1: Type: text/plain, Size: 10233 bytes --]
I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
in particular that of a launcher idea on system to replace alternatives on the
ExecStart= line of a systemd service unit file, alternative ideas are of
course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
a little while ago with nothing concrete being recommended but instead a few
options being now archived as possibilities. I'm looking for a bit wider
review of the approaches and recomendations.
Some general background for non xen folks: old xen requires the launch of
a daemon which implements supports of the xenstore, which is the database
that xen uses for information about guests / dom0. There are two supported
daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
same thing. Right now old init lets you override which one you pick through
an environment variable on /etc/{sysconfig,default}/xencommons, the script
will use the appropriate on there. Systemd doesn't let you use variables on
the ExecStart line of a service unit file so alternatives are required.
The reason I'm being very careful here this could set a precedent and at
least for the launcher idea it'd require the usage of getenv() and execve(),
and secure alternatives for these (secure_getenv(), execve_nosecurity())
have either been merged or suggested before for Linux. The systemd discussion
is only specific to Linux but if we have a launcher we could consider it for
other supported OSes. All that said I'd like proper review of the security
implications of *all* strategies but obviously in particular the launcher
idea. I want to tread carefuly before setting precedents.
Details below as we discuss the approach we can take on Xen.
On Wed, May 28, 2014 at 10:30:49AM +0100, Ian Campbell wrote:
> On Sat, 2014-05-24 at 01:20 +0200, Luis R. Rodriguez wrote:
> > On Thu, May 22, 2014 at 11:05:47AM +0100, Ian Campbell wrote:
> > > On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > > > > It might be reasonable for hotplugpath.sh to define
> > > > > XENSTORE_xenstored=/path/to/xenstored
> > > > > XENSTORE_oxenstored=/path/to/oxenstored
> > > > >
> > > > > and use the existing XENSTORED variable in sysconfig to select which.
> > > >
> > > > Ah but but hotplugpath.sh is one of those automatically generated files
> > > > and after my last patch in this series they are all now shared in one
> > > > master file, config/xen-environment-scripts.in, and since the we want
> > > > to keep script file Shell / Python agnostic checking which one is set
> > > > on sysconfig is not something reasonable to do on that master file.
> > >
> > > Well, it must be possible to change which xenstored implementation is
> > > used by editing a single setting in /etc/{sysconfig,default}/xencommons,
> > > maybe that means more code somewhere, I don't know. idieally you would
> > > be able to say
> > > XENSTORE=xenstored # C xenstore at default path
> > > XENSTORE=oxenstored # Ocaml xenstore at default path
> > > XENSTORE=/path/to/something # xenstored at some custom path.
> >
> > Agreed.
> >
> > > > My series of patches already deals with the old init and xencommons script to
> > > > start xenstore, it used the hotplugpath.sh for deducing the xenstore
> > > > daemon it should use by default and switching this to rely on the sysconfig
> > > > xencommons should be easy if it wasn't already dealt with there already.
> > > >
> > > > For systemd though we can't use varibles on ExecStart for the process, we
> > > > however can use environment variables. We have a few options. Fedora's
> > > > approach was to use two service unit files which conflicted with each other,
> > > > although I'm sure we can work it out by using a target unit and let folks
> > > > flip it seems rather silly to me to maintain two service unit files with
> > > > identical entries. Therefore in my new approach usres would have to manually
> > > > edit the service file with the differnt path / binary. Another possibility
> > > > is to have a central launcher binary that just does getenv() and execve()
> > > > on the desired binary. If this is agreeable I can work on it and it could
> > > > even be shared by the old init as well.
> > >
> > > Which is considered the most "systemd" approach?
> >
> > Systemd tries to even recommend to shy away from sysconfig/default directory for
> > stashing entries, one can set environment variables within the service unit itself,
> > but if we are to maintain compatiblity with old stuff relying on sysconfig seems
> > the reasonable and accepted way, then we'd include that file as part of the
> > running environment, just as our systemd service unit files do now in this series.
>
> I'm mostly concerned that people *not* using systemd can continue to
> use /etc/{default,sysconfig}/xencommons in the way which they are used
> to.
Ah well that is already addressed in the series of patches, I'll be sure to test
flipping it with the xencommons edit on my next respin. I think in my series
the xenstored variable was assumed coming from hotplug.sh and obviously we
just want /etc/{default,sysconfig}/xencommons as expressed I just had missed
that file.
> For people who are using systemd the question is whether it is more or
> less confusing to have an unused /etc/{default,sysconfig}/xencommons
> sitting there vs. doing things in the less "systemd" way. The compromise
> is perhaps to seed the defaults from /e/{d,s}/xencommons but allow them
> to be changed in either that file or in the unit file? Is that possible?
Environment variables cannot be used to replace the binary that systemd will
execute on the ExecStart= line and this is why I mentioned the different
possiblities available. As it stands right now then folks would have to edit
the xenstored.service file and replace the full path of the binary to get
a different xenstore to run, and then and reboot, right now on systemd the file
/e/{d,s}/xencommons could only be used to get daemon environment variables,
not change the daemon. If we can live with that as a compromise in
documentation then that would require only an edit to the file
/e/{d,s}/xencommons and make sure its clear that the daemon override would
only work on legacy init and not systemd. That's another option then, so to
be clear there are these known options:
0) *Iff* we want to loose the /e/{d,s}/xencommons behavior we just document
that the /e/{d,s}/xencommons override is only for legacy init and have
folks edit the service file to change the preferred daemon. They'd
obviously just have to reboot.
*Iff* we want to conserve the /e/{d,s}/xencommons behaviour we have a few options:
1) two service unit files and one target file, the downside is that the service
files are identical except for the ExecStart line, that seems silly then
as you'd have to maintain two files or at least once installed they'd be
nearly identical.
2) two service unit files and use an alias for the general service name,
the same downside applies though.
3) we implement a launcher which will getenv() and execve() the appropriate
daemon. To do this we can rename the C implementation to cxenstored,
the Ocaml daemon remain as oxenstored, and the launcher would get
the generic name xenstored. Although I had not mentioned before I am
making it clear now that I'd like a bit more review on this strategy
and the reasons for it.
Options 1-2 would require no changes to other OSes. Option 3 however could
be considered for integration on other OSes. When evaluating these options
please note that any security issues with getenv() and execve() also have
to be considered in light of the current strategy for legacy init which
would rely on an environment file which allows full override on the binary.
> > More details here:
> >
> > http://0pointer.de/blog/projects/on-etc-sysinit.html
> >
> > As for dynamic use daemons, there aren't good examples but the undocumented way
> > of doing this but as a per a conversation at the LF Linux Collaboration summit
> > one way to deal with this is to use one service target files for defining what
> > we do, we'd have two separate service unit files for each cxenstored and
> > oxenstored, the services that need to depend on it would depend on the target,
> > not the actual service unit files, the user then would have to enable one or
> > the other. A sysconfig edit however would not trigger a change, which is what
> > we seem to want,
>
> What do you mean? I don't expect editing sysconfig will automagically do
> anything, some further action would be required, and since xenstored is
> involved that further action most likely involves a reboot.
Sorry dynamic was the wrong word, what I meant was a way that would not require
a service unit change but rather an environment file much as with the legacy init
approach.
> Can a systemd unit "soft fail"? i.e. fail but not make a huge red
> highlighted fuss about it?
Not that I have seen documented.
> Then each of the two units could check if
> they were configured and softfail if not (expecting that the other one
> is configured). Alternatively perhaps there is some sort of pre-check
> hook which could be used to see if the unit can/should be run?
Option 1) and 2) can be used for something like this if we did not want
to have a system administrator ever involved in selectin between the two
units, but it would then require adding code on both C version of xentored
and on the ocaml oxenstored to getenv() on XENSTORED and fail to load if
it didn't match. I am not sure if two service units that claim the same
alias (option 2) would work well in a situation where one is expected
to fail though. Likewise for the target (option 1). Seems a bit hacky,
but then again so do all of these options and hence the wide review.
IMHO the launcher is the cleanest solution and my preferred strategy
provided of course all possible security concerns and any other concenrs
check out well.
Luis
[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-29 23:29 ` Luis R. Rodriguez
@ 2014-06-01 6:15 ` Lennart Poettering
2014-06-01 6:15 ` Lennart Poettering
1 sibling, 0 replies; 71+ messages in thread
From: Lennart Poettering @ 2014-06-01 6:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, linux-security-module, ebiederm, Jan Beulich,
xen-devel, systemd-devel, morgan
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> in particular that of a launcher idea on system to replace alternatives on the
> ExecStart= line of a systemd service unit file, alternative ideas are of
> course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> a little while ago with nothing concrete being recommended but instead a few
> options being now archived as possibilities. I'm looking for a bit wider
> review of the approaches and recomendations.
>
> Some general background for non xen folks: old xen requires the launch of
> a daemon which implements supports of the xenstore, which is the database
> that xen uses for information about guests / dom0. There are two supported
> daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> same thing. Right now old init lets you override which one you pick through
> an environment variable on /etc/{sysconfig,default}/xencommons, the script
> will use the appropriate on there. Systemd doesn't let you use variables on
> the ExecStart line of a service unit file so alternatives are required.
>
> The reason I'm being very careful here this could set a precedent and at
> least for the launcher idea it'd require the usage of getenv() and execve(),
> and secure alternatives for these (secure_getenv(), execve_nosecurity())
> have either been merged or suggested before for Linux. The systemd discussion
> is only specific to Linux but if we have a launcher we could consider it for
> other supported OSes. All that said I'd like proper review of the security
> implications of *all* strategies but obviously in particular the launcher
> idea. I want to tread carefuly before setting precedents.
You can also just invoke a shell script from ExecStart=. I mean, we try
to deemphesize them in the boot process, but there's nothing wrong with
using shell, if you need to parse shell configuraiton fragments and just
want to execute on ot another program...
That said, I'd certainly make a clean cut and drop support for
/etc/sysconfig from any project I see, earlier rather than later, since
it's just cruft, a bad idea and should really just go away. But then
again, I would also just not do the thing with supporting two
implementations at the same time...
Lennart
--
Lennart Poettering, Red Hat
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-29 23:29 ` Luis R. Rodriguez
2014-06-01 6:15 ` [systemd-devel] " Lennart Poettering
@ 2014-06-01 6:15 ` Lennart Poettering
2014-06-05 0:31 ` Luis R. Rodriguez
2014-06-05 0:31 ` Luis R. Rodriguez
1 sibling, 2 replies; 71+ messages in thread
From: Lennart Poettering @ 2014-06-01 6:15 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ian Campbell, luto, Keir Fraser, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, morgan
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> in particular that of a launcher idea on system to replace alternatives on the
> ExecStart= line of a systemd service unit file, alternative ideas are of
> course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> a little while ago with nothing concrete being recommended but instead a few
> options being now archived as possibilities. I'm looking for a bit wider
> review of the approaches and recomendations.
>
> Some general background for non xen folks: old xen requires the launch of
> a daemon which implements supports of the xenstore, which is the database
> that xen uses for information about guests / dom0. There are two supported
> daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> same thing. Right now old init lets you override which one you pick through
> an environment variable on /etc/{sysconfig,default}/xencommons, the script
> will use the appropriate on there. Systemd doesn't let you use variables on
> the ExecStart line of a service unit file so alternatives are required.
>
> The reason I'm being very careful here this could set a precedent and at
> least for the launcher idea it'd require the usage of getenv() and execve(),
> and secure alternatives for these (secure_getenv(), execve_nosecurity())
> have either been merged or suggested before for Linux. The systemd discussion
> is only specific to Linux but if we have a launcher we could consider it for
> other supported OSes. All that said I'd like proper review of the security
> implications of *all* strategies but obviously in particular the launcher
> idea. I want to tread carefuly before setting precedents.
You can also just invoke a shell script from ExecStart=. I mean, we try
to deemphesize them in the boot process, but there's nothing wrong with
using shell, if you need to parse shell configuraiton fragments and just
want to execute on ot another program...
That said, I'd certainly make a clean cut and drop support for
/etc/sysconfig from any project I see, earlier rather than later, since
it's just cruft, a bad idea and should really just go away. But then
again, I would also just not do the thing with supporting two
implementations at the same time...
Lennart
--
Lennart Poettering, Red Hat
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-01 6:15 ` Lennart Poettering
@ 2014-06-05 0:31 ` Luis R. Rodriguez
2014-06-05 2:52 ` Cameron Norman
` (3 more replies)
2014-06-05 0:31 ` Luis R. Rodriguez
1 sibling, 4 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-06-05 0:31 UTC (permalink / raw)
To: Lennart Poettering
Cc: Ian Campbell, luto, Keir Fraser, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, morgan
[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>
> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > in particular that of a launcher idea on system to replace alternatives on the
> > ExecStart= line of a systemd service unit file, alternative ideas are of
> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > a little while ago with nothing concrete being recommended but instead a few
> > options being now archived as possibilities. I'm looking for a bit wider
> > review of the approaches and recomendations.
> >
> > Some general background for non xen folks: old xen requires the launch of
> > a daemon which implements supports of the xenstore, which is the database
> > that xen uses for information about guests / dom0. There are two supported
> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > same thing. Right now old init lets you override which one you pick through
> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > will use the appropriate on there. Systemd doesn't let you use variables on
> > the ExecStart line of a service unit file so alternatives are required.
> >
> > The reason I'm being very careful here this could set a precedent and at
> > least for the launcher idea it'd require the usage of getenv() and execve(),
> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > have either been merged or suggested before for Linux. The systemd discussion
> > is only specific to Linux but if we have a launcher we could consider it for
> > other supported OSes. All that said I'd like proper review of the security
> > implications of *all* strategies but obviously in particular the launcher
> > idea. I want to tread carefuly before setting precedents.
>
> You can also just invoke a shell script from ExecStart=. I mean, we try
> to deemphesize them in the boot process, but there's nothing wrong with
> using shell, if you need to parse shell configuraiton fragments and just
> want to execute on ot another program...
I tried this and it didn't work given that systemd expects sd_notify()
to be called from the parent process, in this case the shell script.
Anyway -- time has passed folks and we need to pick something, I really
rather not spend any more time on this series unless a decision is made.
My preference stands as the launcher with getenv() and execve() but I
have also listed all other options available. Please feel free to pick
one but just let me know.
> That said, I'd certainly make a clean cut and drop support for
> /etc/sysconfig from any project I see, earlier rather than later, since
> it's just cruft, a bad idea and should really just go away.
We can use for example something like:
# The RPM way
EnvironmentFile=-/etc/sysconfig/xencommons
# The Debian way
EnvironmentFile=-/etc/default/xencommons
Environment=XENSTORED=oxenstored
And with time this lets us with time get rid of EnvironmentFile.
> But then
> again, I would also just not do the thing with supporting two
> implementations at the same time...
:)
Luis
[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 0:31 ` Luis R. Rodriguez
@ 2014-06-05 2:52 ` Cameron Norman
2014-06-10 1:15 ` Luis R. Rodriguez
2014-06-10 1:15 ` Luis R. Rodriguez
2014-06-05 2:52 ` Cameron Norman
` (2 subsequent siblings)
3 siblings, 2 replies; 71+ messages in thread
From: Cameron Norman @ 2014-06-05 2:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Lennart Poettering, luto, Keir Fraser, Ian Campbell, Tim Deegan,
Ian Jackson, linux-kernel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, systemd-devel, morgan
On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
>> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>>
>> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
>> > in particular that of a launcher idea on system to replace alternatives on the
>> > ExecStart= line of a systemd service unit file, alternative ideas are of
>> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
>> > a little while ago with nothing concrete being recommended but instead a few
>> > options being now archived as possibilities. I'm looking for a bit wider
>> > review of the approaches and recomendations.
>> >
>> > Some general background for non xen folks: old xen requires the launch of
>> > a daemon which implements supports of the xenstore, which is the database
>> > that xen uses for information about guests / dom0. There are two supported
>> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
>> > same thing. Right now old init lets you override which one you pick through
>> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
>> > will use the appropriate on there. Systemd doesn't let you use variables on
>> > the ExecStart line of a service unit file so alternatives are required.
>> >
>> > The reason I'm being very careful here this could set a precedent and at
>> > least for the launcher idea it'd require the usage of getenv() and execve(),
>> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
>> > have either been merged or suggested before for Linux. The systemd discussion
>> > is only specific to Linux but if we have a launcher we could consider it for
>> > other supported OSes. All that said I'd like proper review of the security
>> > implications of *all* strategies but obviously in particular the launcher
>> > idea. I want to tread carefuly before setting precedents.
>>
>> You can also just invoke a shell script from ExecStart=. I mean, we try
>> to deemphesize them in the boot process, but there's nothing wrong with
>> using shell, if you need to parse shell configuraiton fragments and just
>> want to execute on ot another program...
>
> I tried this and it didn't work given that systemd expects sd_notify()
> to be called from the parent process, in this case the shell script.
Just use exec before the daemon command. I am pretty certain it can be
just like this:
ExecStart=/bin/sh -c "exec $XENSTORED"
xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
works just fine.
Best,
--
Cameron
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 2:52 ` Cameron Norman
@ 2014-06-10 1:15 ` Luis R. Rodriguez
2014-06-10 1:15 ` Luis R. Rodriguez
1 sibling, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-06-10 1:15 UTC (permalink / raw)
To: Cameron Norman
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module,
Lennart Poettering, ebiederm, Jan Beulich, xen-devel, morgan
On Wed, Jun 04, 2014 at 07:52:56PM -0700, Cameron Norman wrote:
> On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> >> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> >>
> >> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> >> > in particular that of a launcher idea on system to replace alternatives on the
> >> > ExecStart= line of a systemd service unit file, alternative ideas are of
> >> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> >> > a little while ago with nothing concrete being recommended but instead a few
> >> > options being now archived as possibilities. I'm looking for a bit wider
> >> > review of the approaches and recomendations.
> >> >
> >> > Some general background for non xen folks: old xen requires the launch of
> >> > a daemon which implements supports of the xenstore, which is the database
> >> > that xen uses for information about guests / dom0. There are two supported
> >> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> >> > same thing. Right now old init lets you override which one you pick through
> >> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> >> > will use the appropriate on there. Systemd doesn't let you use variables on
> >> > the ExecStart line of a service unit file so alternatives are required.
> >> >
> >> > The reason I'm being very careful here this could set a precedent and at
> >> > least for the launcher idea it'd require the usage of getenv() and execve(),
> >> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> >> > have either been merged or suggested before for Linux. The systemd discussion
> >> > is only specific to Linux but if we have a launcher we could consider it for
> >> > other supported OSes. All that said I'd like proper review of the security
> >> > implications of *all* strategies but obviously in particular the launcher
> >> > idea. I want to tread carefuly before setting precedents.
> >>
> >> You can also just invoke a shell script from ExecStart=. I mean, we try
> >> to deemphesize them in the boot process, but there's nothing wrong with
> >> using shell, if you need to parse shell configuraiton fragments and just
> >> want to execute on ot another program...
> >
> > I tried this and it didn't work given that systemd expects sd_notify()
> > to be called from the parent process, in this case the shell script.
>
> Just use exec before the daemon command. I am pretty certain it can be
> just like this:
>
> ExecStart=/bin/sh -c "exec $XENSTORED"
>
> xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
> works just fine.
Actually this does work on a test unit I just built. I'll proceed with
this approach since I haven't heard back from others and I think
this is the best approach now.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 2:52 ` Cameron Norman
2014-06-10 1:15 ` Luis R. Rodriguez
@ 2014-06-10 1:15 ` Luis R. Rodriguez
1 sibling, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-06-10 1:15 UTC (permalink / raw)
To: Cameron Norman
Cc: Lennart Poettering, luto, Keir Fraser, Ian Campbell, Tim Deegan,
Ian Jackson, linux-kernel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, systemd-devel, morgan
On Wed, Jun 04, 2014 at 07:52:56PM -0700, Cameron Norman wrote:
> On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> >> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> >>
> >> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> >> > in particular that of a launcher idea on system to replace alternatives on the
> >> > ExecStart= line of a systemd service unit file, alternative ideas are of
> >> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> >> > a little while ago with nothing concrete being recommended but instead a few
> >> > options being now archived as possibilities. I'm looking for a bit wider
> >> > review of the approaches and recomendations.
> >> >
> >> > Some general background for non xen folks: old xen requires the launch of
> >> > a daemon which implements supports of the xenstore, which is the database
> >> > that xen uses for information about guests / dom0. There are two supported
> >> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> >> > same thing. Right now old init lets you override which one you pick through
> >> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> >> > will use the appropriate on there. Systemd doesn't let you use variables on
> >> > the ExecStart line of a service unit file so alternatives are required.
> >> >
> >> > The reason I'm being very careful here this could set a precedent and at
> >> > least for the launcher idea it'd require the usage of getenv() and execve(),
> >> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> >> > have either been merged or suggested before for Linux. The systemd discussion
> >> > is only specific to Linux but if we have a launcher we could consider it for
> >> > other supported OSes. All that said I'd like proper review of the security
> >> > implications of *all* strategies but obviously in particular the launcher
> >> > idea. I want to tread carefuly before setting precedents.
> >>
> >> You can also just invoke a shell script from ExecStart=. I mean, we try
> >> to deemphesize them in the boot process, but there's nothing wrong with
> >> using shell, if you need to parse shell configuraiton fragments and just
> >> want to execute on ot another program...
> >
> > I tried this and it didn't work given that systemd expects sd_notify()
> > to be called from the parent process, in this case the shell script.
>
> Just use exec before the daemon command. I am pretty certain it can be
> just like this:
>
> ExecStart=/bin/sh -c "exec $XENSTORED"
>
> xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
> works just fine.
Actually this does work on a test unit I just built. I'll proceed with
this approach since I haven't heard back from others and I think
this is the best approach now.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 0:31 ` Luis R. Rodriguez
2014-06-05 2:52 ` Cameron Norman
@ 2014-06-05 2:52 ` Cameron Norman
2014-06-05 11:22 ` Lennart Poettering
2014-06-05 11:22 ` Lennart Poettering
3 siblings, 0 replies; 71+ messages in thread
From: Cameron Norman @ 2014-06-05 2:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module,
Lennart Poettering, ebiederm, Jan Beulich, xen-devel, morgan
On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
> On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
>> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>>
>> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
>> > in particular that of a launcher idea on system to replace alternatives on the
>> > ExecStart= line of a systemd service unit file, alternative ideas are of
>> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
>> > a little while ago with nothing concrete being recommended but instead a few
>> > options being now archived as possibilities. I'm looking for a bit wider
>> > review of the approaches and recomendations.
>> >
>> > Some general background for non xen folks: old xen requires the launch of
>> > a daemon which implements supports of the xenstore, which is the database
>> > that xen uses for information about guests / dom0. There are two supported
>> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
>> > same thing. Right now old init lets you override which one you pick through
>> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
>> > will use the appropriate on there. Systemd doesn't let you use variables on
>> > the ExecStart line of a service unit file so alternatives are required.
>> >
>> > The reason I'm being very careful here this could set a precedent and at
>> > least for the launcher idea it'd require the usage of getenv() and execve(),
>> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
>> > have either been merged or suggested before for Linux. The systemd discussion
>> > is only specific to Linux but if we have a launcher we could consider it for
>> > other supported OSes. All that said I'd like proper review of the security
>> > implications of *all* strategies but obviously in particular the launcher
>> > idea. I want to tread carefuly before setting precedents.
>>
>> You can also just invoke a shell script from ExecStart=. I mean, we try
>> to deemphesize them in the boot process, but there's nothing wrong with
>> using shell, if you need to parse shell configuraiton fragments and just
>> want to execute on ot another program...
>
> I tried this and it didn't work given that systemd expects sd_notify()
> to be called from the parent process, in this case the shell script.
Just use exec before the daemon command. I am pretty certain it can be
just like this:
ExecStart=/bin/sh -c "exec $XENSTORED"
xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
works just fine.
Best,
--
Cameron
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 0:31 ` Luis R. Rodriguez
2014-06-05 2:52 ` Cameron Norman
2014-06-05 2:52 ` Cameron Norman
@ 2014-06-05 11:22 ` Lennart Poettering
2014-06-05 11:22 ` Lennart Poettering
3 siblings, 0 replies; 71+ messages in thread
From: Lennart Poettering @ 2014-06-05 11:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, linux-security-module, ebiederm, Jan Beulich,
xen-devel, systemd-devel, morgan
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> >
> > > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > > in particular that of a launcher idea on system to replace alternatives on the
> > > ExecStart= line of a systemd service unit file, alternative ideas are of
> > > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > > a little while ago with nothing concrete being recommended but instead a few
> > > options being now archived as possibilities. I'm looking for a bit wider
> > > review of the approaches and recomendations.
> > >
> > > Some general background for non xen folks: old xen requires the launch of
> > > a daemon which implements supports of the xenstore, which is the database
> > > that xen uses for information about guests / dom0. There are two supported
> > > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > > same thing. Right now old init lets you override which one you pick through
> > > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > > will use the appropriate on there. Systemd doesn't let you use variables on
> > > the ExecStart line of a service unit file so alternatives are required.
> > >
> > > The reason I'm being very careful here this could set a precedent and at
> > > least for the launcher idea it'd require the usage of getenv() and execve(),
> > > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > > have either been merged or suggested before for Linux. The systemd discussion
> > > is only specific to Linux but if we have a launcher we could consider it for
> > > other supported OSes. All that said I'd like proper review of the security
> > > implications of *all* strategies but obviously in particular the launcher
> > > idea. I want to tread carefuly before setting precedents.
> >
> > You can also just invoke a shell script from ExecStart=. I mean, we try
> > to deemphesize them in the boot process, but there's nothing wrong with
> > using shell, if you need to parse shell configuraiton fragments and just
> > want to execute on ot another program...
>
> I tried this and it didn't work given that systemd expects sd_notify()
> to be called from the parent process, in this case the shell script.
Hmm? You should "exec" the real daemon binary at the end, not just fork
it off. That wait the shell script process is replaced by the daemon
binary, which is what you want.
Lennart
--
Lennart Poettering, Red Hat
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 0:31 ` Luis R. Rodriguez
` (2 preceding siblings ...)
2014-06-05 11:22 ` Lennart Poettering
@ 2014-06-05 11:22 ` Lennart Poettering
2014-06-05 18:01 ` Luis R. Rodriguez
2014-06-05 18:01 ` Luis R. Rodriguez
3 siblings, 2 replies; 71+ messages in thread
From: Lennart Poettering @ 2014-06-05 11:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ian Campbell, luto, Keir Fraser, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, morgan
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> >
> > > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > > in particular that of a launcher idea on system to replace alternatives on the
> > > ExecStart= line of a systemd service unit file, alternative ideas are of
> > > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > > a little while ago with nothing concrete being recommended but instead a few
> > > options being now archived as possibilities. I'm looking for a bit wider
> > > review of the approaches and recomendations.
> > >
> > > Some general background for non xen folks: old xen requires the launch of
> > > a daemon which implements supports of the xenstore, which is the database
> > > that xen uses for information about guests / dom0. There are two supported
> > > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > > same thing. Right now old init lets you override which one you pick through
> > > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > > will use the appropriate on there. Systemd doesn't let you use variables on
> > > the ExecStart line of a service unit file so alternatives are required.
> > >
> > > The reason I'm being very careful here this could set a precedent and at
> > > least for the launcher idea it'd require the usage of getenv() and execve(),
> > > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > > have either been merged or suggested before for Linux. The systemd discussion
> > > is only specific to Linux but if we have a launcher we could consider it for
> > > other supported OSes. All that said I'd like proper review of the security
> > > implications of *all* strategies but obviously in particular the launcher
> > > idea. I want to tread carefuly before setting precedents.
> >
> > You can also just invoke a shell script from ExecStart=. I mean, we try
> > to deemphesize them in the boot process, but there's nothing wrong with
> > using shell, if you need to parse shell configuraiton fragments and just
> > want to execute on ot another program...
>
> I tried this and it didn't work given that systemd expects sd_notify()
> to be called from the parent process, in this case the shell script.
Hmm? You should "exec" the real daemon binary at the end, not just fork
it off. That wait the shell script process is replaced by the daemon
binary, which is what you want.
Lennart
--
Lennart Poettering, Red Hat
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 11:22 ` Lennart Poettering
@ 2014-06-05 18:01 ` Luis R. Rodriguez
2014-06-05 19:24 ` Lennart Poettering
2014-06-05 19:24 ` Lennart Poettering
2014-06-05 18:01 ` Luis R. Rodriguez
1 sibling, 2 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-06-05 18:01 UTC (permalink / raw)
To: Lennart Poettering
Cc: Ian Campbell, luto, Keir Fraser, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, morgan
On Thu, Jun 05, 2014 at 01:22:13PM +0200, Lennart Poettering wrote:
> On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>
> > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> > > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> > >
> > > > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > > > in particular that of a launcher idea on system to replace alternatives on the
> > > > ExecStart= line of a systemd service unit file, alternative ideas are of
> > > > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > > > a little while ago with nothing concrete being recommended but instead a few
> > > > options being now archived as possibilities. I'm looking for a bit wider
> > > > review of the approaches and recomendations.
> > > >
> > > > Some general background for non xen folks: old xen requires the launch of
> > > > a daemon which implements supports of the xenstore, which is the database
> > > > that xen uses for information about guests / dom0. There are two supported
> > > > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > > > same thing. Right now old init lets you override which one you pick through
> > > > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > > > will use the appropriate on there. Systemd doesn't let you use variables on
> > > > the ExecStart line of a service unit file so alternatives are required.
> > > >
> > > > The reason I'm being very careful here this could set a precedent and at
> > > > least for the launcher idea it'd require the usage of getenv() and execve(),
> > > > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > > > have either been merged or suggested before for Linux. The systemd discussion
> > > > is only specific to Linux but if we have a launcher we could consider it for
> > > > other supported OSes. All that said I'd like proper review of the security
> > > > implications of *all* strategies but obviously in particular the launcher
> > > > idea. I want to tread carefuly before setting precedents.
> > >
> > > You can also just invoke a shell script from ExecStart=. I mean, we try
> > > to deemphesize them in the boot process, but there's nothing wrong with
> > > using shell, if you need to parse shell configuraiton fragments and just
> > > want to execute on ot another program...
> >
> > I tried this and it didn't work given that systemd expects sd_notify()
> > to be called from the parent process, in this case the shell script.
>
> Hmm? You should "exec" the real daemon binary at the end, not just fork
> it off. That wait the shell script process is replaced by the daemon
> binary, which is what you want.
I tried both just running it and also running exec foo; both presented
the same issue given that shell exec does not really execve.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 18:01 ` Luis R. Rodriguez
@ 2014-06-05 19:24 ` Lennart Poettering
2014-06-05 19:24 ` Lennart Poettering
1 sibling, 0 replies; 71+ messages in thread
From: Lennart Poettering @ 2014-06-05 19:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, linux-security-module, ebiederm, Jan Beulich,
xen-devel, systemd-devel, morgan
On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> > Hmm? You should "exec" the real daemon binary at the end, not just fork
> > it off. That wait the shell script process is replaced by the daemon
> > binary, which is what you want.
>
> I tried both just running it and also running exec foo; both presented
> the same issue given that shell exec does not really execve.
Hmmm? You shell's "exec" command doesn't actually execve()? What are you
using? This doesn't sound very accurate...
Lennart
--
Lennart Poettering, Red Hat
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 18:01 ` Luis R. Rodriguez
2014-06-05 19:24 ` Lennart Poettering
@ 2014-06-05 19:24 ` Lennart Poettering
2014-06-05 19:26 ` Andrew Lutomirski
2014-06-05 19:26 ` Andrew Lutomirski
1 sibling, 2 replies; 71+ messages in thread
From: Lennart Poettering @ 2014-06-05 19:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ian Campbell, luto, Keir Fraser, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, morgan
On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> > Hmm? You should "exec" the real daemon binary at the end, not just fork
> > it off. That wait the shell script process is replaced by the daemon
> > binary, which is what you want.
>
> I tried both just running it and also running exec foo; both presented
> the same issue given that shell exec does not really execve.
Hmmm? You shell's "exec" command doesn't actually execve()? What are you
using? This doesn't sound very accurate...
Lennart
--
Lennart Poettering, Red Hat
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 19:24 ` Lennart Poettering
@ 2014-06-05 19:26 ` Andrew Lutomirski
2014-06-05 19:26 ` Andrew Lutomirski
1 sibling, 0 replies; 71+ messages in thread
From: Andrew Lutomirski @ 2014-06-05 19:26 UTC (permalink / raw)
To: Lennart Poettering
Cc: Keir Fraser, Ian Campbell, Tim Deegan, Luis R. Rodriguez,
Ian Jackson, linux-kernel, linux-security-module, Eric Biederman,
Jan Beulich, xen-devel, systemd-devel, Andrew G. Morgan
On Thu, Jun 5, 2014 at 12:24 PM, Lennart Poettering
<mzxreary@0pointer.de> wrote:
> On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>
>> > Hmm? You should "exec" the real daemon binary at the end, not just fork
>> > it off. That wait the shell script process is replaced by the daemon
>> > binary, which is what you want.
>>
>> I tried both just running it and also running exec foo; both presented
>> the same issue given that shell exec does not really execve.
>
> Hmmm? You shell's "exec" command doesn't actually execve()? What are you
> using? This doesn't sound very accurate...
$ strace -e execve /bin/sh -c 'exec /bin/echo test'
execve("/bin/sh", ["/bin/sh", "-c", "exec /bin/echo test"], [/* 54 vars */]) = 0
execve("/bin/echo", ["/bin/echo", "test"], [/* 54 vars */]) = 0
test
+++ exited with 0 +++
I get similar results on Ubuntu using dash.
--Andy
^ permalink raw reply [flat|nested] 71+ messages in thread* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 19:24 ` Lennart Poettering
2014-06-05 19:26 ` Andrew Lutomirski
@ 2014-06-05 19:26 ` Andrew Lutomirski
1 sibling, 0 replies; 71+ messages in thread
From: Andrew Lutomirski @ 2014-06-05 19:26 UTC (permalink / raw)
To: Lennart Poettering
Cc: Luis R. Rodriguez, Ian Campbell, Keir Fraser, Tim Deegan,
Ian Jackson, linux-kernel, systemd-devel, linux-security-module,
Eric Biederman, Jan Beulich, xen-devel, Andrew G. Morgan
On Thu, Jun 5, 2014 at 12:24 PM, Lennart Poettering
<mzxreary@0pointer.de> wrote:
> On Thu, 05.06.14 20:01, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>
>> > Hmm? You should "exec" the real daemon binary at the end, not just fork
>> > it off. That wait the shell script process is replaced by the daemon
>> > binary, which is what you want.
>>
>> I tried both just running it and also running exec foo; both presented
>> the same issue given that shell exec does not really execve.
>
> Hmmm? You shell's "exec" command doesn't actually execve()? What are you
> using? This doesn't sound very accurate...
$ strace -e execve /bin/sh -c 'exec /bin/echo test'
execve("/bin/sh", ["/bin/sh", "-c", "exec /bin/echo test"], [/* 54 vars */]) = 0
execve("/bin/echo", ["/bin/echo", "test"], [/* 54 vars */]) = 0
test
+++ exited with 0 +++
I get similar results on Ubuntu using dash.
--Andy
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-05 11:22 ` Lennart Poettering
2014-06-05 18:01 ` Luis R. Rodriguez
@ 2014-06-05 18:01 ` Luis R. Rodriguez
1 sibling, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-06-05 18:01 UTC (permalink / raw)
To: Lennart Poettering
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, linux-security-module, ebiederm, Jan Beulich,
xen-devel, systemd-devel, morgan
On Thu, Jun 05, 2014 at 01:22:13PM +0200, Lennart Poettering wrote:
> On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>
> > On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> > > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
> > >
> > > > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > > > in particular that of a launcher idea on system to replace alternatives on the
> > > > ExecStart= line of a systemd service unit file, alternative ideas are of
> > > > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > > > a little while ago with nothing concrete being recommended but instead a few
> > > > options being now archived as possibilities. I'm looking for a bit wider
> > > > review of the approaches and recomendations.
> > > >
> > > > Some general background for non xen folks: old xen requires the launch of
> > > > a daemon which implements supports of the xenstore, which is the database
> > > > that xen uses for information about guests / dom0. There are two supported
> > > > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > > > same thing. Right now old init lets you override which one you pick through
> > > > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > > > will use the appropriate on there. Systemd doesn't let you use variables on
> > > > the ExecStart line of a service unit file so alternatives are required.
> > > >
> > > > The reason I'm being very careful here this could set a precedent and at
> > > > least for the launcher idea it'd require the usage of getenv() and execve(),
> > > > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > > > have either been merged or suggested before for Linux. The systemd discussion
> > > > is only specific to Linux but if we have a launcher we could consider it for
> > > > other supported OSes. All that said I'd like proper review of the security
> > > > implications of *all* strategies but obviously in particular the launcher
> > > > idea. I want to tread carefuly before setting precedents.
> > >
> > > You can also just invoke a shell script from ExecStart=. I mean, we try
> > > to deemphesize them in the boot process, but there's nothing wrong with
> > > using shell, if you need to parse shell configuraiton fragments and just
> > > want to execute on ot another program...
> >
> > I tried this and it didn't work given that systemd expects sd_notify()
> > to be called from the parent process, in this case the shell script.
>
> Hmm? You should "exec" the real daemon binary at the end, not just fork
> it off. That wait the shell script process is replaced by the daemon
> binary, which is what you want.
I tried both just running it and also running exec foo; both presented
the same issue given that shell exec does not really execve.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-06-01 6:15 ` Lennart Poettering
2014-06-05 0:31 ` Luis R. Rodriguez
@ 2014-06-05 0:31 ` Luis R. Rodriguez
1 sibling, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-06-05 0:31 UTC (permalink / raw)
To: Lennart Poettering
Cc: luto, Keir Fraser, Ian Campbell, Tim Deegan, Ian Jackson,
linux-kernel, linux-security-module, ebiederm, Jan Beulich,
xen-devel, systemd-devel, morgan
[-- Attachment #1.1: Type: text/plain, Size: 3297 bytes --]
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcgrof@suse.com) wrote:
>
> > I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
> > in particular that of a launcher idea on system to replace alternatives on the
> > ExecStart= line of a systemd service unit file, alternative ideas are of
> > course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
> > a little while ago with nothing concrete being recommended but instead a few
> > options being now archived as possibilities. I'm looking for a bit wider
> > review of the approaches and recomendations.
> >
> > Some general background for non xen folks: old xen requires the launch of
> > a daemon which implements supports of the xenstore, which is the database
> > that xen uses for information about guests / dom0. There are two supported
> > daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
> > same thing. Right now old init lets you override which one you pick through
> > an environment variable on /etc/{sysconfig,default}/xencommons, the script
> > will use the appropriate on there. Systemd doesn't let you use variables on
> > the ExecStart line of a service unit file so alternatives are required.
> >
> > The reason I'm being very careful here this could set a precedent and at
> > least for the launcher idea it'd require the usage of getenv() and execve(),
> > and secure alternatives for these (secure_getenv(), execve_nosecurity())
> > have either been merged or suggested before for Linux. The systemd discussion
> > is only specific to Linux but if we have a launcher we could consider it for
> > other supported OSes. All that said I'd like proper review of the security
> > implications of *all* strategies but obviously in particular the launcher
> > idea. I want to tread carefuly before setting precedents.
>
> You can also just invoke a shell script from ExecStart=. I mean, we try
> to deemphesize them in the boot process, but there's nothing wrong with
> using shell, if you need to parse shell configuraiton fragments and just
> want to execute on ot another program...
I tried this and it didn't work given that systemd expects sd_notify()
to be called from the parent process, in this case the shell script.
Anyway -- time has passed folks and we need to pick something, I really
rather not spend any more time on this series unless a decision is made.
My preference stands as the launcher with getenv() and execve() but I
have also listed all other options available. Please feel free to pick
one but just let me know.
> That said, I'd certainly make a clean cut and drop support for
> /etc/sysconfig from any project I see, earlier rather than later, since
> it's just cruft, a bad idea and should really just go away.
We can use for example something like:
# The RPM way
EnvironmentFile=-/etc/sysconfig/xencommons
# The Debian way
EnvironmentFile=-/etc/default/xencommons
Environment=XENSTORED=oxenstored
And with time this lets us with time get rid of EnvironmentFile.
> But then
> again, I would also just not do the thing with supporting two
> implementations at the same time...
:)
Luis
[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
2014-05-28 9:30 ` Ian Campbell
2014-05-29 16:09 ` Don Koch
2014-05-29 23:29 ` Luis R. Rodriguez
@ 2014-05-29 23:29 ` Luis R. Rodriguez
2 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-29 23:29 UTC (permalink / raw)
To: Ian Campbell, luto
Cc: Keir Fraser, Luis R. Rodriguez, Tim Deegan, Ian Jackson,
linux-kernel, systemd-devel, linux-security-module, ebiederm,
Jan Beulich, xen-devel, morgan
[-- Attachment #1.1: Type: text/plain, Size: 10233 bytes --]
I'm cc'ing a few security folks as I'd appreciate review on the ideas here,
in particular that of a launcher idea on system to replace alternatives on the
ExecStart= line of a systemd service unit file, alternative ideas are of
course welcomed. I'm also Cc'ing systemd-devel as this subject was reviewed
a little while ago with nothing concrete being recommended but instead a few
options being now archived as possibilities. I'm looking for a bit wider
review of the approaches and recomendations.
Some general background for non xen folks: old xen requires the launch of
a daemon which implements supports of the xenstore, which is the database
that xen uses for information about guests / dom0. There are two supported
daemons, xenstored (C version) and oxenstored (Ocaml version) but they do the
same thing. Right now old init lets you override which one you pick through
an environment variable on /etc/{sysconfig,default}/xencommons, the script
will use the appropriate on there. Systemd doesn't let you use variables on
the ExecStart line of a service unit file so alternatives are required.
The reason I'm being very careful here this could set a precedent and at
least for the launcher idea it'd require the usage of getenv() and execve(),
and secure alternatives for these (secure_getenv(), execve_nosecurity())
have either been merged or suggested before for Linux. The systemd discussion
is only specific to Linux but if we have a launcher we could consider it for
other supported OSes. All that said I'd like proper review of the security
implications of *all* strategies but obviously in particular the launcher
idea. I want to tread carefuly before setting precedents.
Details below as we discuss the approach we can take on Xen.
On Wed, May 28, 2014 at 10:30:49AM +0100, Ian Campbell wrote:
> On Sat, 2014-05-24 at 01:20 +0200, Luis R. Rodriguez wrote:
> > On Thu, May 22, 2014 at 11:05:47AM +0100, Ian Campbell wrote:
> > > On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > > > > It might be reasonable for hotplugpath.sh to define
> > > > > XENSTORE_xenstored=/path/to/xenstored
> > > > > XENSTORE_oxenstored=/path/to/oxenstored
> > > > >
> > > > > and use the existing XENSTORED variable in sysconfig to select which.
> > > >
> > > > Ah but but hotplugpath.sh is one of those automatically generated files
> > > > and after my last patch in this series they are all now shared in one
> > > > master file, config/xen-environment-scripts.in, and since the we want
> > > > to keep script file Shell / Python agnostic checking which one is set
> > > > on sysconfig is not something reasonable to do on that master file.
> > >
> > > Well, it must be possible to change which xenstored implementation is
> > > used by editing a single setting in /etc/{sysconfig,default}/xencommons,
> > > maybe that means more code somewhere, I don't know. idieally you would
> > > be able to say
> > > XENSTORE=xenstored # C xenstore at default path
> > > XENSTORE=oxenstored # Ocaml xenstore at default path
> > > XENSTORE=/path/to/something # xenstored at some custom path.
> >
> > Agreed.
> >
> > > > My series of patches already deals with the old init and xencommons script to
> > > > start xenstore, it used the hotplugpath.sh for deducing the xenstore
> > > > daemon it should use by default and switching this to rely on the sysconfig
> > > > xencommons should be easy if it wasn't already dealt with there already.
> > > >
> > > > For systemd though we can't use varibles on ExecStart for the process, we
> > > > however can use environment variables. We have a few options. Fedora's
> > > > approach was to use two service unit files which conflicted with each other,
> > > > although I'm sure we can work it out by using a target unit and let folks
> > > > flip it seems rather silly to me to maintain two service unit files with
> > > > identical entries. Therefore in my new approach usres would have to manually
> > > > edit the service file with the differnt path / binary. Another possibility
> > > > is to have a central launcher binary that just does getenv() and execve()
> > > > on the desired binary. If this is agreeable I can work on it and it could
> > > > even be shared by the old init as well.
> > >
> > > Which is considered the most "systemd" approach?
> >
> > Systemd tries to even recommend to shy away from sysconfig/default directory for
> > stashing entries, one can set environment variables within the service unit itself,
> > but if we are to maintain compatiblity with old stuff relying on sysconfig seems
> > the reasonable and accepted way, then we'd include that file as part of the
> > running environment, just as our systemd service unit files do now in this series.
>
> I'm mostly concerned that people *not* using systemd can continue to
> use /etc/{default,sysconfig}/xencommons in the way which they are used
> to.
Ah well that is already addressed in the series of patches, I'll be sure to test
flipping it with the xencommons edit on my next respin. I think in my series
the xenstored variable was assumed coming from hotplug.sh and obviously we
just want /etc/{default,sysconfig}/xencommons as expressed I just had missed
that file.
> For people who are using systemd the question is whether it is more or
> less confusing to have an unused /etc/{default,sysconfig}/xencommons
> sitting there vs. doing things in the less "systemd" way. The compromise
> is perhaps to seed the defaults from /e/{d,s}/xencommons but allow them
> to be changed in either that file or in the unit file? Is that possible?
Environment variables cannot be used to replace the binary that systemd will
execute on the ExecStart= line and this is why I mentioned the different
possiblities available. As it stands right now then folks would have to edit
the xenstored.service file and replace the full path of the binary to get
a different xenstore to run, and then and reboot, right now on systemd the file
/e/{d,s}/xencommons could only be used to get daemon environment variables,
not change the daemon. If we can live with that as a compromise in
documentation then that would require only an edit to the file
/e/{d,s}/xencommons and make sure its clear that the daemon override would
only work on legacy init and not systemd. That's another option then, so to
be clear there are these known options:
0) *Iff* we want to loose the /e/{d,s}/xencommons behavior we just document
that the /e/{d,s}/xencommons override is only for legacy init and have
folks edit the service file to change the preferred daemon. They'd
obviously just have to reboot.
*Iff* we want to conserve the /e/{d,s}/xencommons behaviour we have a few options:
1) two service unit files and one target file, the downside is that the service
files are identical except for the ExecStart line, that seems silly then
as you'd have to maintain two files or at least once installed they'd be
nearly identical.
2) two service unit files and use an alias for the general service name,
the same downside applies though.
3) we implement a launcher which will getenv() and execve() the appropriate
daemon. To do this we can rename the C implementation to cxenstored,
the Ocaml daemon remain as oxenstored, and the launcher would get
the generic name xenstored. Although I had not mentioned before I am
making it clear now that I'd like a bit more review on this strategy
and the reasons for it.
Options 1-2 would require no changes to other OSes. Option 3 however could
be considered for integration on other OSes. When evaluating these options
please note that any security issues with getenv() and execve() also have
to be considered in light of the current strategy for legacy init which
would rely on an environment file which allows full override on the binary.
> > More details here:
> >
> > http://0pointer.de/blog/projects/on-etc-sysinit.html
> >
> > As for dynamic use daemons, there aren't good examples but the undocumented way
> > of doing this but as a per a conversation at the LF Linux Collaboration summit
> > one way to deal with this is to use one service target files for defining what
> > we do, we'd have two separate service unit files for each cxenstored and
> > oxenstored, the services that need to depend on it would depend on the target,
> > not the actual service unit files, the user then would have to enable one or
> > the other. A sysconfig edit however would not trigger a change, which is what
> > we seem to want,
>
> What do you mean? I don't expect editing sysconfig will automagically do
> anything, some further action would be required, and since xenstored is
> involved that further action most likely involves a reboot.
Sorry dynamic was the wrong word, what I meant was a way that would not require
a service unit change but rather an environment file much as with the legacy init
approach.
> Can a systemd unit "soft fail"? i.e. fail but not make a huge red
> highlighted fuss about it?
Not that I have seen documented.
> Then each of the two units could check if
> they were configured and softfail if not (expecting that the other one
> is configured). Alternatively perhaps there is some sort of pre-check
> hook which could be used to see if the unit can/should be run?
Option 1) and 2) can be used for something like this if we did not want
to have a system administrator ever involved in selectin between the two
units, but it would then require adding code on both C version of xentored
and on the ocaml oxenstored to getenv() on XENSTORED and fail to load if
it didn't match. I am not sure if two service units that claim the same
alias (option 2) would work well in a situation where one is expected
to fail though. Likewise for the target (option 1). Seems a bit hacky,
but then again so do all of these options and hence the wide review.
IMHO the launcher is the cleanest solution and my preferred strategy
provided of course all possible security concerns and any other concenrs
check out well.
Luis
[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v5 13/14] xencommons: move module list into a generic place
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (11 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 13:40 ` Jan Beulich
[not found] ` <537B776D020000780001425E@suse.com>
2014-05-20 12:31 ` [PATCH v5 14/14] systemd: add xen systemd service and module files Luis R. Rodriguez
13 siblings, 2 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel; +Cc: Luis R. Rodriguez
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This will allows us to share the same module list with
sysemd, 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#Linux_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>
---
Please run ./autgen.sh after this patch is applied.
README | 18 +++++++++++
config/modules | 16 ++++++++++
tools/hotplug/Linux/Makefile | 36 +++++++++++++++++++---
.../Linux/init.d/{xencommons => xencommons.in} | 16 +---------
4 files changed, 67 insertions(+), 19 deletions(-)
create mode 100644 config/modules
rename tools/hotplug/Linux/init.d/{xencommons => xencommons.in} (88%)
diff --git a/README b/README
index 4183b34..480a829 100644
--- a/README
+++ b/README
@@ -179,6 +179,24 @@ generated at build time after running ./configure.
[1] http://wiki.xen.org/wiki/XenStoreReference
[2] http://wiki.xen.org/wiki/Xenstored
+Required Linux modules
+======================
+
+Xen has a set of Linux modules which the init scripts ensure to load before
+enablement of xen guests. The list of modules are upkept in one place:
+
+ * config/modules
+
+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.
+
+We should strive to not require statically loading modules but it seems some
+systems have had issues with automatically loading some Linux kernel modules.
+For more details refer to:
+
+http://wiki.xen.org/wiki/Category:Host_Configuration#Linux_kernel_modules
+
Python Runtime Libraries
========================
diff --git a/config/modules b/config/modules
new file mode 100644
index 0000000..525c60e
--- /dev/null
+++ b/config/modules
@@ -0,0 +1,16 @@
+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..90b0b0c 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -33,17 +33,45 @@ 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/modules $(XENCOMMONS_INITD).in
+ @set -e ; \
+ IFS='' ;\
+ cat $(XEN_ROOT)/config/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
.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 +83,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 88%
rename from tools/hotplug/Linux/init.d/xencommons
rename to tools/hotplug/Linux/init.d/xencommons.in
index 2bb6f26..a0484a0 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`
--
2.0.0.rc3.18.g00a5b79
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 13/14] xencommons: move module list into a generic place
2014-05-20 12:31 ` [PATCH v5 13/14] xencommons: move module list into a generic place Luis R. Rodriguez
@ 2014-05-20 13:40 ` Jan Beulich
[not found] ` <537B776D020000780001425E@suse.com>
1 sibling, 0 replies; 71+ messages in thread
From: Jan Beulich @ 2014-05-20 13:40 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: xen-devel, Luis Rodriguez
>>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This will allows us to share the same module list with
> sysemd, and lets us upkeep it in one place.
Hmm - do we really want to further play with this module loading,
which for at least two releases was scheduled to be removed in
favor of having the tool stack load modules on demand?
Jan
^ permalink raw reply [flat|nested] 71+ messages in thread[parent not found: <537B776D020000780001425E@suse.com>]
* Re: [PATCH v5 13/14] xencommons: move module list into a generic place
[not found] ` <537B776D020000780001425E@suse.com>
@ 2014-05-20 18:03 ` Luis R. Rodriguez
0 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 18:03 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, Luis R. Rodriguez
On Tue, May 20, 2014 at 07:40:29AM -0600, Jan Beulich wrote:
> >>> On 20.05.14 at 14:31, <mcgrof@do-not-panic.com> wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > This will allows us to share the same module list with
> > sysemd, and lets us upkeep it in one place.
>
> Hmm - do we really want to further play with this module loading,
That seems to be orthogonal as I'm not adding or removing extensions to it but
simply preserving the existing behavior for both old init and systemd, if
anything just documenting the existing behavior.
In the last series the modules stuff was discussed and it was pointed out a
desire to share and retain only one source for the list of modules, this is why
I addressed this in this series. A few regressions were mentioned that seemed
to still exist with auto module loading on Linux, this is why this is
preserved.
> which for at least two releases was scheduled to be removed in
> favor of having the tool stack load modules on demand?
If this support gets added to the tool stack then both systemd and old
init can just remove this part, however the modules xen.conf service unit
file might to then be replaced by an ExecStartPre. The *right* solution
at least for Linux, as documented in the README is to really fix auto
module loading. For Linux at least it would help have documented on the
wiki the exact bug numbers for those issues that exist where auto module
loading does not work.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v5 14/14] systemd: add xen systemd service and module files
2014-05-20 12:31 [PATCH v5 00/14] xen: add systemd support Luis R. Rodriguez
` (12 preceding siblings ...)
2014-05-20 12:31 ` [PATCH v5 13/14] xencommons: move module list into a generic place Luis R. Rodriguez
@ 2014-05-20 12:31 ` Luis R. Rodriguez
2014-05-20 12:48 ` Luis R. Rodriguez
13 siblings, 1 reply; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:31 UTC (permalink / raw)
To: xen-devel
Cc: Ian Campbell, Stefano Stabellini, Luis R. Rodriguez,
Jan Rękorajski, Ian Jackson, Jacek Konieczny, M A Young
From: "Luis R. Rodriguez" <mcgrof@suse.com>
This adds the systemd xen service / module files. All of this
is disabled for now, and won't install / build until we hook
up proper support for systemd 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
things should still work as we use the dynamic linker
loader through dlopen() and dlsym(). Only systems that
have booted into systemd as its init system are expected
to have systemd libraries present at run time. Binaries
built with systemd support enabled do not need systemd
libaries present unless they actually booted with
systemd as their init.
These are originally based on the Fedora systemd files.
Changes made from Fedora's systemd files:
* enables systemd socket activation for C xenstored and Ocaml
oxenstored, this uses the dynamic link loader to enable support
for one binary under both systemd and non systemd systems.
* use sd_notify(), so change the service to Type=notify, because of
this we remove the PIDFile spefification as we don't care, and let
systemd do its magic for us, this also means we don't have to fork
so we use --no-fork
* 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. It is technically possible to support
multiple service files to the two different xenstored's but this is
rather pointless right now specially since we cannot stop [co]xenstored.
We instead strive for simplicity with one direct target build
service file.
* 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 the socket 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
* 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
* 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 targetted
by default when building on Linux systems if systemd enabled at
build time, 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.
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>
---
Please run ./autgen.sh after this patch is applied.
.gitignore | 5 +
Makefile | 6 +-
README | 28 +++++
config/Tools.mk.in | 6 ++
m4/README.source | 7 ++
m4/systemd.m4 | 120 +++++++++++++++++++++
tools/configure.ac | 14 ++-
tools/hotplug/Linux/Makefile | 8 +-
tools/hotplug/Linux/systemd/Makefile | 70 ++++++++++++
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 ++
17 files changed, 390 insertions(+), 5 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
diff --git a/.gitignore b/.gitignore
index fd1b627..5ece576 100644
--- a/.gitignore
+++ b/.gitignore
@@ -390,3 +390,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..104e39d 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 480a829..cb85c5a 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
@@ -197,6 +198,33 @@ For more details refer to:
http://wiki.xen.org/wiki/Category:Host_Configuration#Linux_kernel_modules
+Systemd and legacy init support
+===============================
+
+If you have systemd development packages installed you can build binaries
+that will work for both old init systems and also for systems booted with the
+systemd init replacement by using the configure --enable-systemd flag. When
+systemd is enabled all systemd support gets tucked away under a the shared
+xenstore library libxenstore.so. Systemd support is provided in libxenstore.so
+though the dynamic linking loader (dlopen(), dlsym()) by run time checking
+of the library libsystemd-daemon.so. Only systems that we can verify that
+booted with systemd as its init are expected to work with systemd, otherwise
+the old socket are initialization mechanism is used. If a system has
+libsystemd-daemon.so but it did not boot with systemd the old socket
+initialization mechanism is used. Systems that do not have libsystemd-daemon.so
+will end up using the old socket initialization mechanism. Systemd enables
+active socket activation for the xenstored unix sockets, which can be
+claimed by cxenstored or oxenstored during initialization.
+
+For now even if you have systemd libararies present systemd enablement
+is left disabled, to enable systemd you must use --enable-systemd on
+configure. Systemd may be enabled by default in the future if systemd
+development libraries are present after thorough testing.
+
+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 84b2612..fbaf11e 100644
--- a/config/Tools.mk.in
+++ b/config/Tools.mk.in
@@ -57,6 +57,12 @@ CONFIG_BLKTAP1 := @blktap1@
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 76f7c5a..a3b0fe6 100644
--- a/m4/README.source
+++ b/m4/README.source
@@ -26,3 +26,10 @@ 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>,
+it has no home project but the goal is to generalize this and actually
+upstream it into systemd.
diff --git a/m4/systemd.m4 b/m4/systemd.m4
new file mode 100644
index 0000000..9108173
--- /dev/null
+++ b/m4/systemd.m4
@@ -0,0 +1,120 @@
+# 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, dnl 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], [
+ AS_IF([test "x$systemd" = "xy" ], [
+ AC_DEFINE([HAVE_SYSTEMD], [1], [Systemd available and enabled])
+ systemd=y
+ AX_CHECK_SYSTEMD_LIBS()
+ ],[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 470894a..d8135cc 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -5,7 +5,17 @@ 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/systemd/proc-xen.mount
+hotplug/Linux/systemd/var-lib-xenstored.mount
+hotplug/Linux/systemd/xenstored.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([../])
@@ -48,6 +58,7 @@ m4_include([../m4/extfs.m4])
m4_include([../m4/fetcher.m4])
m4_include([../m4/ax_compare_version.m4])
m4_include([../m4/expand_config.m4])
+m4_include([../m4/systemd.m4])
AX_XEN_EXPAND_CONFIG()
@@ -250,5 +261,6 @@ esac
# Checks for header files.
AC_CHECK_HEADERS([yajl/yajl_version.h sys/eventfd.h])
+AX_AVAILABLE_SYSTEMD()
AC_OUTPUT()
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 90b0b0c..7d8af99 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/modules $(XENCOMMONS_INITD).in
@set -e ; \
@@ -67,7 +69,7 @@ $(XENCOMMONS_INITD): $(XEN_ROOT)/config/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
@@ -105,4 +107,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..2301e85
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/Makefile
@@ -0,0 +1,70 @@
+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_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:
+ rm -f *.socket *.service *.mount *.conf
+
+.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/modules
+ @set -e ; \
+ IFS='' ;\
+ cat $(XEN_ROOT)/config/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 \
+ ) > $@
+
+.PHONY: clean
+clean:
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..e49d9d4
--- /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=
+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..e1ed116
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xenstored.service.in
@@ -0,0 +1,27 @@
+[Unit]
+Description=Xenstored - daemon managing xenstore file system
+Requires=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
+ConditionFileIsExecutable=@XENSTORED@
+
+[Service]
+Type=notify
+Environment=XENSTORED_ARGS=
+Environment=XENSTORED_ROOTDIR=@XEN_LIB_STORED@
+EnvironmentFile=-/etc/default/xenstored
+EnvironmentFile=-/etc/sysconfig/xenstored
+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=@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.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..7d998ab
--- /dev/null
+++ b/tools/hotplug/Linux/systemd/xenstored.socket.in
@@ -0,0 +1,11 @@
+[Unit]
+Description=Xen xenstored / oxenstored Activation Socket
+ConditionVirtualization=xen
+
+[Socket]
+ListenStream=/var/run/xenstored/socket
+ListenStream=/var/run/xenstored/socket_ro
+SocketMode=0600
+
+[Install]
+WantedBy=sockets.target
--
2.0.0.rc3.18.g00a5b79
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 71+ messages in thread* Re: [PATCH v5 14/14] systemd: add xen systemd service and module files
2014-05-20 12:31 ` [PATCH v5 14/14] systemd: add xen systemd service and module files Luis R. Rodriguez
@ 2014-05-20 12:48 ` Luis R. Rodriguez
0 siblings, 0 replies; 71+ messages in thread
From: Luis R. Rodriguez @ 2014-05-20 12:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ian Campbell, Stefano Stabellini, Jan Rękorajski,
Ian Jackson, Jacek Konieczny, M A Young, xen-devel
On Tue, May 20, 2014 at 05:31:35AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This adds the systemd xen service / module files. All of this
> is disabled for now, and won't install / build until we hook
> up proper support for systemd into the build system.
You can ignore the above paragraph except hte first sentence
as this added the autconf stuff too. It could be split up
but I guess I decided to merge it. It should be easy to tell
how to split it up though, just the autconf stuff is what
would be left out and moved to a separate patch.
Luis
^ permalink raw reply [flat|nested] 71+ messages in thread