[systemd-devel] [PATCH 0/3] build-sys: do not require intltool when building from archive
Hi Zbigniew, This set of patches does explicit handling of --disable-nls and some extra detection of intltool in order to make configure not fail when intltool is not present. It also ships the translated *.policy files in the distribution tarball. This makes it possible to build from an archive without having intltool installed, as the systemd README implies (intltool is only listed under When building from git, you need the following additional dependencies.) Please take a look and let me know what you think of these. Cheers, Filipe Filipe Brandenburger (3): build-sys: add explicit support for --diable-nls build-sys: check if intltool is present before initializing it build-sys: include PolicyKit files as part of distribution Makefile.am | 2 +- configure.ac | 14 ++ 2 files changed, 15 insertions(+), 1 deletion(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] build-sys: disable NLS support if intltool is not found
IT_PROG_INTLTOOL makes configure fail if intltool is not present. If we can not find intltool, then disable NLS (otherwise make in po/ fails since MSGFMT will not be defined.) Tested: Built it on a host without intltool. $ ./configure --enable-nls ... checking for intltool-merge... no configure: error: --enable-nls requested but intltool not found $ ./configure --disable-polkit ... checking for intltool-merge... no configure: WARNING: *** Disabling NLS support because intltool was not found checking whether NLS is requested... no ... $ make --- configure.ac | 12 1 file changed, 12 insertions(+) diff --git a/configure.ac b/configure.ac index 31879d3fb410..93aba067397c 100644 --- a/configure.ac +++ b/configure.ac @@ -49,6 +49,18 @@ AS_IF([test x$enable_static = xyes], [AC_MSG_ERROR([--enable-static is not s AS_IF([test x$enable_largefile = xno], [AC_MSG_ERROR([--disable-largefile is not supported by systemd])]) # i18n stuff for the PolicyKit policy files + +# Check whether intltool can be found, disable NLS otherwise +AC_CHECK_PROG(intltool_found, [intltool-merge], [yes], [no]) +AS_IF([test x$intltool_found != xyes], + [AS_IF([test x$enable_nls = xyes], + [AC_MSG_ERROR([--enable-nls requested but intltool not found])], + [AS_IF([test x$enable_nls != xno], +[AC_MSG_WARN([*** Disabling NLS support because intltool was not found]) + enable_nls=no]) + ]) + ]) + AM_NLS AS_IF([test x$enable_nls != xno], [ # intltoolize greps for '^(AC|IT)_PROG_INTLTOOL', so it needs to be on its own line -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] build-sys: include PolicyKit files as part of distribution
So that building from an archive works even if intltool is not present. The README file already mentioned that intltool should only be required when building from git. Tested: Built it from the distribution archive on a host without intltool. $ ./configure --enable-polkit $ make --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 4b292b210531..94ea4d10ae0c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -5170,7 +5170,7 @@ units/user/%: units/%.m4 $(AM_V_M4)$(M4) -P $(M4_DEFINES) -DFOR_USER=1 $ $@ if ENABLE_POLKIT -nodist_polkitpolicy_DATA = \ +dist_polkitpolicy_DATA = \ $(polkitpolicy_files) \ $(polkitpolicy_in_in_files:.policy.in.in=.policy) endif -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] build-sys: add explicit support for --diable-nls
In particular, disable intltool when --disable-nls is passed to configure. Tested: Built it on a host without intltool or gettext. $ ./configure --disable-nls --disable-polkit $ make --- configure.ac | 10 ++ 1 file changed, 10 insertions(+) diff --git a/configure.ac b/configure.ac index bb6018f87dec..31879d3fb410 100644 --- a/configure.ac +++ b/configure.ac @@ -49,7 +49,17 @@ AS_IF([test x$enable_static = xyes], [AC_MSG_ERROR([--enable-static is not s AS_IF([test x$enable_largefile = xno], [AC_MSG_ERROR([--disable-largefile is not supported by systemd])]) # i18n stuff for the PolicyKit policy files +AM_NLS +AS_IF([test x$enable_nls != xno], [ +# intltoolize greps for '^(AC|IT)_PROG_INTLTOOL', so it needs to be on its own line IT_PROG_INTLTOOL([0.40.0]) +]) + +AS_IF([test -z $INTLTOOL_POLICY_RULE], [ +# If intltool is not available, provide a dummy rule to fail generation of %.policy files with a meaningful error message +INTLTOOL_POLICY_RULE='%.policy: %.policy.in ; @echo ITMRG$@ echo *** intltool support required to build target $@ false' +AC_SUBST(INTLTOOL_POLICY_RULE) +]) GETTEXT_PACKAGE=systemd AC_SUBST(GETTEXT_PACKAGE) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/3] build-sys: do not require intltool when building from archive
On 25/06/14 09:06, Filipe Brandenburger wrote:
Hi Zbigniew,
This set of patches does explicit handling of --disable-nls and some extra
detection of intltool in order to make configure not fail when intltool is not
present.
For reference, we are using this workaround to disable intltool when
it's not installed
in the Gentoo build script for a minimal build of selected components.
I'm only mentioning it here in case some other packagers need a workaround.
Executed right before starting ./configure:
sed -i -e '/INTLTOOL_APPLIED_VERSION=/s:=.*:=0.40.0:' configure
sed -i -e '/XML::Parser perl module is required for intltool/s|^|:|'
configure
eval export INTLTOOL_{EXTRACT,MERGE,UPDATE}=/bin/true
eval export {MSG{FMT,MERGE},XGETTEXT}=/bin/true
That's all.
Thanks,
Samuli
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Cocci] systemd m4 library complex systemd example, and coccinelle conversion
On Mon, Jun 23, 2014 at 03:19:30PM +0200, Lennart Poettering wrote: On Thu, 12.06.14 18:04, Luis R. Rodriguez (mcg...@do-not-panic.com) wrote: Hey folks, so I've been working on getting systemd support on xen for a bit now and thanks to the last suggestion about the launcher here on systemd-devel I think we're on the final stretch now. I'll be submitting a v6 PATCH series shortly which I think should be the last if not close to the last set we need. It turns out though that I ran into quite a few issues though, what I consider corner cases with systemd, and in order to help I've tried to put together a simple package example source code which exemplifies the complexities I found but more importantly provide the resolutions to those issues. At the same time xen also is a good example of a complex piece of software with multiple OS requirements and on the Linux font you may or may not want systemd, it also happened to use autoconf, but not automake, and in one iteration of patches I even worked on systemd support with the dynamic link loader (dlopen() and dlsym()). Adding proper support for systemd into xen turned out to be a bit of a mini project. In order to try to help other though I've generalized as much as I can the autotools functionality I wrote given I was unable to find a library to easily add systemd. I'd like your review of this piece of code and wanted to see if perhaps at least the LGPL m4 libraries might be welcomed. * src/m4/systemd.m4 - AX_ENABLE_SYSTEMD(): enables systemd by default and requires an explicit --disable-systemd option flag to configure if you want to disable systemd support. - AX_ALLOW_SYSTEMD(): systemd will be disabled by default and requires you to run configure with --enable-systemd to look for and enable systemd - AX_AVAILABLE_SYSTEMD(): systemd will be disabled by default but if your build system is detected to have systemd build libraries it will be enabled. You can always force disable with --disable-systemd - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. Hmm, so, I don't think systemd should really be treated differently from other pkg-config-enabled modules. What precisely does this add that pkg-config doesn't support? And wouldn't it be possible to improve pkg-config upstream instead? pkg-config is a helper to let you figure out what you have installed, flags required, etc. It doesn't do the autoconf voodoo dance which is simply a nightmare. Relying on pkg-config also assumes systemd has done the right job on all aspects of variables but as the m4 library annotates there a few areas where this could be enhanced so it tries to centralize this on an m4 library for userspace. I don't think we want to support the dlsym() stuff in systemd directly. I mean, if people want to do things like that, that's fine, but I really doubt we should encourage that from upstream. Makes sense, its an option and the vodoo is done, if they inist the purpose of the funkd-systemd code is to say -- its done, and go at it, here's an example. Also note that pretty much any Linux distributions (modulo Gentoo/Slackware) uses systemd already or announced plans to do so, I am not sure it's worth really investing so much time in making systemd optional beyond the usual what pkg-config supports. It wasn't clear to me while learning about systemd so I was just agnostic to that. Its all there as options, people can choose. Lastly -- I was curious if anyone has looked into writing Coccinelle SmPL grammar rules to convert legacy init systems with systemd support. I suspect most unix daemons are rather simple and SmPL rules might be able to transform quite a bit of them. I don't expect Coccinelle might be able to catch the crazy daemons with corner cases as with xen, but you never know, coccinelle is always surprising me with its capabilities. Note that distribuitions like Fedora have already pretty much converted all their daemons (with exceptions), so I figure this in many ways is too late... Conversion to me means sd_notify(), what does it mean to you? Either way stats can help with this specially to inspire folks who may wish to convert daemons from legacy init script port to proper sd_notify(), or from fork to sd_notify(). Granted we can't expect full conversion on the simple service type to sd_notify() easily but what I was aiming for here in the argument for SmPL was to see what was left from legacy fork to sd_notify(). Luis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [PATCH] networkd: Introduce tuntap device
On Tue, 24.06.14 23:21, Susant Sahani (sus...@redhat.com) wrote: This patch introduces tuntap support to networkd. Example conf file : tuntap.netdev [NetDev] Name=tuntap-test Kind=tuntap [TUNTAP] Hm, maybe call this TunTap instead? Mode=tap OneQueue=true MultiQueue=true PacketInfo=true I wonder if it might be better separate in Tun and in Tap devices. Tun devices are IP only devices and Tap devices are actual Ethernet devices. It looks a bit silly that you have to specific Kind=tuntap only to later specific Mode=tap. Why not just do Kind=tap device? That under Linux the setup of both Tun and Tap devices happens via /dev/net/tun is just an implementation detail. The intention behind keeping Kind=tuntap is related to the driver. Kind - driver Mode- how it behaves . Of cource what you saying is correct implementation details but Kind is related to the driver. I fully agree with Marcel. We shouldn't expose users too directly to implementation details of the kernel. The fact that usually the Kind maps to the low-level driver doesn't mean we have to map it always 1:1. In this case it really makes more sense to map one driver (tuntap) into two different Kinds (tun + tap). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH 3/3] coredump: compress core files
On Wed, 25.06.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Hi, a POC patch to compress coredumps after they are written. In my simple tests, this brings huge savings, because the compressed coredump can compress to ~5%. Unfortunately the core is first written uncompressed, then compressed by reading from disk and writing to the output file. This is ugly and slow, but I don't see a way around, if we want to get the backtrace without keeping everything in memory. I have the suspicion that there indeed is no other nice way for this... Hence looks good to me. 'coredumpctl gdb' is not implemented yet (the decompression part is missing). Hmm, we probably should add a coredump.conf option for this to turn on. Hmm, thinking about this, another idea might be to simply let the fs solve this by adding a high-level coredump.conf option to turn on FS_COMPR_FL for the coredump. This should do the right thing on btrfs (afaics at least), but of course would leave other file systems out. But then again, we develop the OS for tomorrow, not for yesterday here... But then again, maybe this stuff shouldn't be exclusive. Maybe a new coredump.conf option Compress=(filesystem|file|no) or so? (and maybe even Compress=auto, which does the right thing automatically, depending if the fs supports compression) After all, doing both file-level and filesystem-level compression makes little sense... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 1/8] (bugfix) undefined member, len, in struct kdbus_pool_slice
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org --- pool.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pool.c b/pool.c index d896d9b..4267c54 100644 --- a/pool.c +++ b/pool.c @@ -623,7 +623,7 @@ void kdbus_pool_slice_flush(const struct kdbus_pool_slice *slice) #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1 struct address_space *mapping = slice-pool-f-f_mapping; pgoff_t first = slice-off PAGE_CACHE_SHIFT; - pgoff_t last = (slice-off + slice-len + + pgoff_t last = (slice-off + slice-size + PAGE_CACHE_SIZE-1) PAGE_CACHE_SHIFT; pgoff_t i; -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 2/8] (debug) add a debug message and others
lib_dump and lib_verbose variables are used only in my benchmark programs
for additional debug messages. You can ignore them for performance
evaluation.
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
test/kdbus-util.c |4
test/kdbus-util.h |3 +++
2 files changed, 7 insertions(+)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 5316263..6c2c5db 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -26,6 +26,9 @@
#include kdbus-util.h
#include kdbus-enum.h
+int lib_dump = 0;
+int lib_verbose = 0;
+
#define POOL_SIZE (16 * 1024LU * 1024LU)
static struct conn *
__kdbus_hello(const char *path, uint64_t flags,
@@ -320,6 +323,7 @@ void msg_dump(const struct conn *conn, const struct
kdbus_msg *msg)
else
cookie_reply = msg-cookie_reply;
+ printf(MESSAGE: from %lld, to %lld\n, msg-src_id, msg-dst_id);
printf(MESSAGE: %s (%llu bytes) flags=0x%08llx, %s ??? %s,
cookie=%llu, timeout=%llu cookie_reply=%llu priority=%lli\n,
enum_PAYLOAD(msg-payload_type), (unsigned long long)msg-size,
(unsigned long long)msg-flags,
diff --git a/test/kdbus-util.h b/test/kdbus-util.h
index fde3f77..acdc34f 100644
--- a/test/kdbus-util.h
+++ b/test/kdbus-util.h
@@ -36,6 +36,9 @@ struct conn {
size_t size;
};
+extern int lib_dump;
+extern int lib_verbose;
+
int name_list(struct conn *conn, uint64_t flags);
int name_release(struct conn *conn, const char *name);
int name_acquire(struct conn *conn, const char *name, uint64_t flags);
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 8/8] add makefile flags to turn on and off my hacks
KDBUS_HACKx: 1 = enabled, 0 = disabled Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org --- Makefile |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c593b51..3b1 100644 --- a/Makefile +++ b/Makefile @@ -20,13 +20,15 @@ obj-m += kdbus$(EXT).o KERNELDIR ?= /lib/modules/$(shell uname -r)/build PWD:= $(shell pwd) +KDBUS_HACKS ?= -DKDBUS_HACK1=0 -DKDBUS_HACK2=0 -DKDBUS_HACK3=0 + all: module test test:: $(MAKE) -C test KBUILD_MODNAME=kdbus$(EXT) module: - $(MAKE) -C $(KERNELDIR) M=$(PWD) + $(MAKE) -C $(KERNELDIR) M=$(PWD) KCFLAGS=$(KDBUS_HACKS) clean: rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 4/8] HACK0: allow meta information customizable
My ftrace log shows that kdbus_meta_append(), is one of dominant functions
in sending a message, while the other is kdbus_conn_queue_alloc().
This patch adds an extra argument to kdbus_hello() utility function and
allows us to explicitly specify meta information attached to a message
for performance evaluation.
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
test/kdbus-util.c | 35 +--
test/kdbus-util.h |2 ++
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 2cac8be..ef5e0b7 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -31,7 +31,7 @@ int lib_verbose = 0;
#define POOL_SIZE (16 * 1024LU * 1024LU)
static struct conn *
-__kdbus_hello(const char *path, uint64_t flags,
+__kdbus_hello(const char *path, uint64_t flags, uint64_t attach_flags,
const struct kdbus_item *item, size_t item_size)
{
int fd, ret;
@@ -58,17 +58,7 @@ __kdbus_hello(const char *path, uint64_t flags,
h.hello.conn_flags = flags | KDBUS_HELLO_ACCEPT_FD;
- h.hello.attach_flags = KDBUS_ATTACH_TIMESTAMP |
- KDBUS_ATTACH_CREDS |
- KDBUS_ATTACH_NAMES |
- KDBUS_ATTACH_COMM |
- KDBUS_ATTACH_EXE |
- KDBUS_ATTACH_CMDLINE |
- KDBUS_ATTACH_CAPS |
- KDBUS_ATTACH_CGROUP |
- KDBUS_ATTACH_SECLABEL |
- KDBUS_ATTACH_AUDIT |
- KDBUS_ATTACH_CONN_NAME;
+ h.hello.attach_flags = attach_flags;
h.type = KDBUS_ITEM_CONN_NAME;
h.size = KDBUS_ITEM_HEADER_SIZE + sizeof(h.comm);
@@ -109,7 +99,24 @@ __kdbus_hello(const char *path, uint64_t flags,
struct conn *kdbus_hello(const char *path, uint64_t flags)
{
- return __kdbus_hello(path, flags, NULL, 0);
+ uint64_t attach_flags = (KDBUS_ATTACH_TIMESTAMP |
+ KDBUS_ATTACH_CREDS |
+ KDBUS_ATTACH_NAMES |
+ KDBUS_ATTACH_COMM |
+ KDBUS_ATTACH_EXE |
+ KDBUS_ATTACH_CMDLINE |
+ KDBUS_ATTACH_CAPS |
+ KDBUS_ATTACH_CGROUP |
+ KDBUS_ATTACH_SECLABEL |
+ KDBUS_ATTACH_AUDIT |
+ KDBUS_ATTACH_CONN_NAME);
+ return __kdbus_hello(path, flags, attach_flags, NULL, 0);
+}
+
+struct conn *kdbus_hello2(const char *path, uint64_t flags,
+ uint64_t attach_flags)
+{
+ return __kdbus_hello(path, flags, attach_flags, NULL, 0);
}
static struct conn *
@@ -144,7 +151,7 @@ kdbus_hello_registrar(const char *path, const char *name,
item = KDBUS_ITEM_NEXT(item);
}
- return __kdbus_hello(path, flags, items, size);
+ return __kdbus_hello(path, flags, 0 /*FIXME*/, items, size);
}
struct conn *kdbus_hello_activator(const char *path, const char *name,
diff --git a/test/kdbus-util.h b/test/kdbus-util.h
index be6ccab..3f9ff78 100644
--- a/test/kdbus-util.h
+++ b/test/kdbus-util.h
@@ -49,6 +49,8 @@ char *msg_id(uint64_t id, char *buf);
int msg_send(const struct conn *conn, const char *name, uint64_t cookie,
uint64_t flags, uint64_t timeout, int64_t priority, uint64_t
dst_id);
struct conn *kdbus_hello(const char *path, uint64_t hello_flags);
+struct conn *kdbus_hello2(const char *path, uint64_t hello_flags,
+ uint64_t attach_flags);
struct conn *kdbus_hello_activator(const char *path, const char *name,
const struct kdbus_policy_access *access,
size_t num_access);
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 3/8] test/kdbus-util: add lookup_name() for benchmark program
Kdbus can use a name, instead of id, directly as a destination of
message, while Android has an external service manager which is some kind
of (service-)name lookup agent.
By adding lookup_name() to kdbus utility, I'd like to retain the similarity
between binder's and kdbus's bencharmk programs aiming to merge both into
one in the future.
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
test/kdbus-util.c | 38 ++
test/kdbus-util.h |1 +
2 files changed, 39 insertions(+)
diff --git a/test/kdbus-util.c b/test/kdbus-util.c
index 6c2c5db..2cac8be 100644
--- a/test/kdbus-util.c
+++ b/test/kdbus-util.c
@@ -605,6 +605,44 @@ int name_list(struct conn *conn, uint64_t flags)
return 0;
}
+int64_t lookup_name(struct conn *conn, uint64_t flags, const char *svcname)
+{
+ struct kdbus_cmd_name_list cmd_list;
+ struct kdbus_name_list *list;
+ struct kdbus_cmd_name *name;
+ int ret;
+ int64_t id = -1;
+
+ cmd_list.flags = flags;
+
+ ret = ioctl(conn-fd, KDBUS_CMD_NAME_LIST, cmd_list);
+ if (ret 0) {
+ fprintf(stderr, error listing names: %d (%m)\n, ret);
+ return EXIT_FAILURE;
+ }
+
+ printf(REGISTRY:\n);
+ list = (struct kdbus_name_list *)(conn-buf + cmd_list.offset);
+ KDBUS_ITEM_FOREACH(name, list, names) {
+ printf(%8llu flags=0x%08llx conn=0x%08llx '%s'\n,
name-owner_id,
+ name-flags, name-conn_flags,
+ name-size sizeof(struct kdbus_cmd_name) ? name-name
: );
+ if (!strcmp(svcname, name-name)) {
+ id = name-owner_id;
+ break;
+ }
+ }
+ printf(\n);
+
+ ret = ioctl(conn-fd, KDBUS_CMD_FREE, cmd_list.offset);
+ if (ret 0) {
+ fprintf(stderr, error free name list: %d (%m)\n, ret);
+ return EXIT_FAILURE;
+ }
+
+ return id;
+}
+
void add_match_empty(int fd)
{
struct {
diff --git a/test/kdbus-util.h b/test/kdbus-util.h
index acdc34f..be6ccab 100644
--- a/test/kdbus-util.h
+++ b/test/kdbus-util.h
@@ -40,6 +40,7 @@ extern int lib_dump;
extern int lib_verbose;
int name_list(struct conn *conn, uint64_t flags);
+int64_t lookup_name(struct conn *conn, uint64_t flags, const char *name);
int name_release(struct conn *conn, const char *name);
int name_acquire(struct conn *conn, const char *name, uint64_t flags);
int msg_recv(struct conn *conn);
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 7/8] HACK3: minimize the range of D-Cache flush in ioctl(CMD_MSG_RECV)
Current ioctl(CMD_MSG_RECV) contains an expensive cache operation. Even if
the data is quite small, it always executes D-Cache flush on a buffer
at minimum unit of one page in kdbus_conn_msg_install() /
kdbus_pool_slice_flush() .
In fact, flush_dcache_page() implementation is very expensive on ARM since
flushing is repeated at every cache line in a page. This may not be seen on
x86 because it doesn't have ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE on.
This patch replaces flush_dcache_page() by flush_kernel_vmap_range() with
the exact offset and size of slice. (Actually aligned to a cache-line size).
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
pool.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/pool.c b/pool.c
index fcc54af..b723dd2 100644
--- a/pool.c
+++ b/pool.c
@@ -28,6 +28,13 @@
#include pool.h
#include util.h
+/*
+ * KDBUS_HACK3: Do dcache-flush only against the minimum range of slice
+ */
+#if KDBUS_HACK3
+#include asm/cacheflush.h
+#endif
+
/**
* struct kdbus_pool - the receiver's buffer
* @f: The backing shmem file
@@ -194,7 +201,13 @@ struct kdbus_pool_slice *kdbus_pool_slice_find(struct
kdbus_pool *pool,
int kdbus_pool_slice_alloc(struct kdbus_pool *pool,
struct kdbus_pool_slice **slice, size_t size)
{
+#if KDBUS_HACK3
+ /* FIXME: Assume that the cache line size is 128B. */
+#define DCACHE_ALIGN(size) ((size + 0x7f) ~0x7fUL)
+ size_t slice_size = DCACHE_ALIGN(size);
+#else
size_t slice_size = KDBUS_ALIGN8(size);
+#endif
struct rb_node *n, *found = NULL;
struct kdbus_pool_slice *s;
int ret = 0;
@@ -620,6 +633,9 @@ exit_free:
*/
void kdbus_pool_slice_flush(const struct kdbus_pool_slice *slice)
{
+#if KDBUS_HACK3
+ flush_kernel_vmap_range((void *)slice-off, slice-size);
+#else
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1
struct address_space *mapping = slice-pool-f-f_mapping;
pgoff_t first = slice-off PAGE_CACHE_SHIFT;
@@ -638,6 +654,7 @@ void kdbus_pool_slice_flush(const struct kdbus_pool_slice
*slice)
put_page(page);
}
#endif
+#endif
}
/**
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC 5/8] HACK1: optimize copy operations in kdbus_conn_queue_alloc()
This function copies the reply message directly into receiver's buffer
(pool slice). Looking into the implementation closely, however, there are
multiple occurrences of copy operations, kdbus_pool_slice_copy(), which
then executes costly prolog/epilog functions, say set_fs() and
write_begin/write_end(), on each entry/exit.
This patch uses a temporary buffer on the stack to compose a message and
replace a costly function, kdbus_pool_slice_copy(), to memcpy() wherever
possible, although I have to further confirm that this change is actually
safe.
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
connection.c | 98 ++
pool.c |2 +-
pool.h |3 ++
3 files changed, 102 insertions(+), 1 deletion(-)
diff --git a/connection.c b/connection.c
index 40cf133..d122be8 100644
--- a/connection.c
+++ b/connection.c
@@ -39,6 +39,10 @@
#include policy.h
#include util.h
+/*
+ * KDBUS_HACK1: optimize copy operations in kdbus_conn_queue_alloc()
+ */
+
struct kdbus_conn_reply;
/**
@@ -232,7 +236,11 @@ exit_unref:
static int kdbus_conn_payload_add(struct kdbus_conn *conn,
struct kdbus_conn_queue *queue,
const struct kdbus_kmsg *kmsg,
+#if KDBUS_HACK1
+ void *buf, size_t items, size_t vec_data)
+#else
size_t items, size_t vec_data)
+#endif
{
const struct kdbus_item *item;
int ret;
@@ -253,8 +261,13 @@ static int kdbus_conn_payload_add(struct kdbus_conn *conn,
KDBUS_ITEMS_SIZE(kmsg-msg, items)) {
switch (item-type) {
case KDBUS_ITEM_PAYLOAD_VEC: {
+#if KDBUS_HACK1
+ u64 tmp[(KDBUS_ITEM_HEADER_SIZE +
+sizeof(struct kdbus_vec) + 7)/8];
+#else
char tmp[KDBUS_ITEM_HEADER_SIZE +
sizeof(struct kdbus_vec)];
+#endif
struct kdbus_item *it = (struct kdbus_item *)tmp;
/* add item */
@@ -267,10 +280,14 @@ static int kdbus_conn_payload_add(struct kdbus_conn *conn,
else
it-vec.offset = ~0ULL;
it-vec.size = item-vec.size;
+#if KDBUS_HACK1
+ memcpy(buf + items, it, (size_t)it-size);
+#else
ret = kdbus_pool_slice_copy(queue-slice, items,
it, it-size);
if (ret 0)
return ret;
+#endif
items += KDBUS_ALIGN8(it-size);
/* \0-bytes record */
@@ -286,17 +303,28 @@ static int kdbus_conn_payload_add(struct kdbus_conn *conn,
* null-bytes to the buffer which the \0-bytes
* record would have shifted the alignment.
*/
+#if KDBUS_HACK1
+ memset(buf + vec_data, 0, pad);
+#else
kdbus_pool_slice_copy(queue-slice, vec_data,
\0\0\0\0\0\0\0, pad);
+#endif
vec_data += pad;
break;
}
/* copy kdbus_vec data from sender to receiver */
+#if KDBUS_HACK1
+ if (copy_from_user(buf + vec_data,
+ KDBUS_PTR(item-vec.address),
+ (size_t)item-vec.size))
+ return -EFAULT;
+#else
ret = kdbus_pool_slice_copy_user(queue-slice, vec_data,
KDBUS_PTR(item-vec.address), item-vec.size);
if (ret 0)
return ret;
+#endif
vec_data += item-vec.size;
break;
@@ -314,10 +342,14 @@ static int kdbus_conn_payload_add(struct kdbus_conn *conn,
it-size = sizeof(tmp);
it-memfd.size = item-memfd.size;
it-memfd.fd = -1;
+#if KDBUS_HACK1
+ memcpy(buf + items, it, (size_t)it-size);
+#else
ret = kdbus_pool_slice_copy(queue-slice, items,
it, it-size);
if (ret 0)
return ret;
+#endif
/* grab reference of incoming file */
ret = kdbus_conn_memfd_ref(item, fp);
@@ -459,7 +491,13 @@ static int kdbus_conn_queue_alloc(struct kdbus_conn *conn,
size_t fds = 0;
size_t meta = 0;
size_t vec_data;
+#if KDBUS_HACK1
+ size_t want;
+ char *tmp;
+ struct kdbus_item *it;
+#else
[systemd-devel] [RFC 6/8] HACK2: blocking ioctl(CMD_MSG_RECV)
In the current implementation, ioctl(CMD_MSG_RECV) returns immediately if
no message has been queued, and so a service process has to wait by
explicitly calling poll() system call. If such a process needs to wait only
on a single connection, we can eliminate poll() system call by adding a
synchronous attribute in receiving a message.
This patch allows us to specify a flag, KDBUS_HELLO_BLOCK, in HELLO command
and enable the feature. Please note that this is a quick hack, ignoring how
this feature and poll() could co-exist.
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
connection.c | 39 +++
connection.h |1 +
kdbus.h |1 +
3 files changed, 41 insertions(+)
diff --git a/connection.c b/connection.c
index d122be8..5969ead 100644
--- a/connection.c
+++ b/connection.c
@@ -41,6 +41,7 @@
/*
* KDBUS_HACK1: optimize copy operations in kdbus_conn_queue_alloc()
+ * KDBUS_HACK2: add a blocking attribute to ioctl(CMD_MSG_RECV)
*/
struct kdbus_conn_reply;
@@ -795,6 +796,11 @@ static int kdbus_conn_queue_insert(struct kdbus_conn *conn,
/* wake up poll() */
wake_up_interruptible(conn-wait);
+#if KDBUS_HACK2
+ if (conn-flags | KDBUS_HELLO_BLOCK)
+ wake_up_interruptible(conn-wait_recv);
+#endif
+
return 0;
exit_queue_free:
@@ -1024,9 +1030,31 @@ int kdbus_cmd_msg_recv(struct kdbus_conn *conn,
int ret = 0;
mutex_lock(conn-lock);
+recv_again:
if (conn-msg_count == 0) {
+#if KDBUS_HACK2
+ if (conn-flags | KDBUS_HELLO_BLOCK) {
+ mutex_unlock(conn-lock);
+ /* FIXME: there is a small window here. */
+ wait_event_interruptible(conn-wait_recv,
+conn-msg_count);
+ mutex_lock(conn-lock);
+ if (signal_pending(current)) {
+ ret = -EINTR;
+ goto exit_unlock;
+ } else if (conn-disconnected) {
+ ret = -ESHUTDOWN;
+ goto exit_unlock;
+ }
+ goto recv_again;
+ } else {
+ ret = -EAGAIN;
+ goto exit_unlock;
+ }
+#else
ret = -EAGAIN;
goto exit_unlock;
+#endif
}
if (recv-offset 0) {
@@ -1606,6 +1634,10 @@ int kdbus_conn_disconnect(struct kdbus_conn *conn, bool
ensure_queue_empty)
/* wake up the queue so that users can get a POLLERR */
wake_up_interruptible(conn-wait);
+#if KDBUS_HACK2
+ if (conn-flags | KDBUS_HELLO_BLOCK)
+ wake_up_interruptible(conn-wait_recv);
+#endif
kdbus_notify_id_change(conn-bus, KDBUS_ITEM_ID_REMOVE, conn-id,
conn-flags);
@@ -1748,6 +1780,10 @@ int kdbus_conn_move_messages(struct kdbus_conn *conn_dst,
/* wake up poll() */
wake_up_interruptible(conn_dst-wait);
+#if KDBUS_HACK2
+ if (conn_dst-flags | KDBUS_HELLO_BLOCK)
+ wake_up_interruptible(conn_dst-wait_recv);
+#endif
return ret;
}
@@ -2058,6 +2094,9 @@ int kdbus_conn_new(struct kdbus_ep *ep,
INIT_DELAYED_WORK(conn-work, kdbus_conn_work);
conn-cred = current_cred();
init_waitqueue_head(conn-wait);
+#if KDBUS_HACK2
+ init_waitqueue_head(conn-wait_recv);
+#endif
/* init entry, so we can unconditionally remove it */
INIT_LIST_HEAD(conn-monitor_entry);
diff --git a/connection.h b/connection.h
index 46f7b6e..17a05b8 100644
--- a/connection.h
+++ b/connection.h
@@ -92,6 +92,7 @@ struct kdbus_conn {
size_t msg_count;
atomic_t reply_count;
wait_queue_head_t wait;
+ wait_queue_head_t wait_recv;
};
struct kdbus_kmsg;
diff --git a/kdbus.h b/kdbus.h
index 0b189cb..8f91f49 100644
--- a/kdbus.h
+++ b/kdbus.h
@@ -492,6 +492,7 @@ enum kdbus_hello_flags {
KDBUS_HELLO_ACTIVATOR = 1 1,
KDBUS_HELLO_POLICY_HOLDER = 1 2,
KDBUS_HELLO_MONITOR = 1 3,
+ KDBUS_HELLO_BLOCK = 1 4,
};
/**
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tuntap device
On 06/25/2014 02:21 PM, Lennart Poettering wrote: On Tue, 24.06.14 23:21, Susant Sahani (sus...@redhat.com) wrote: This patch introduces tuntap support to networkd. Example conf file : tuntap.netdev [NetDev] Name=tuntap-test Kind=tuntap [TUNTAP] Hm, maybe call this TunTap instead? Mode=tap OneQueue=true MultiQueue=true PacketInfo=true I wonder if it might be better separate in Tun and in Tap devices. Tun devices are IP only devices and Tap devices are actual Ethernet devices. It looks a bit silly that you have to specific Kind=tuntap only to later specific Mode=tap. Why not just do Kind=tap device? That under Linux the setup of both Tun and Tap devices happens via /dev/net/tun is just an implementation detail. The intention behind keeping Kind=tuntap is related to the driver. Kind - driver Mode- how it behaves . Of cource what you saying is correct implementation details but Kind is related to the driver. I fully agree with Marcel. We shouldn't expose users too directly to implementation details of the kernel. The fact that usually the Kind maps to the low-level driver doesn't mean we have to map it always 1:1. In this case it really makes more sense to map one driver (tuntap) into two different Kinds (tun + tap). We can abstract that Agreed . Lennart -- Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tuntap device
On 06/25/2014 02:51 PM, Susant Sahani wrote: On 06/25/2014 02:21 PM, Lennart Poettering wrote: On Tue, 24.06.14 23:21, Susant Sahani (sus...@redhat.com) wrote: This patch introduces tuntap support to networkd. Example conf file : tuntap.netdev [NetDev] Name=tuntap-test Kind=tuntap [TUNTAP] Do we need to keep this section different as well ? for example [Tun] and [Tap] Hm, maybe call this TunTap instead? Mode=tap OneQueue=true MultiQueue=true PacketInfo=true I wonder if it might be better separate in Tun and in Tap devices. Tun devices are IP only devices and Tap devices are actual Ethernet devices. It looks a bit silly that you have to specific Kind=tuntap only to later specific Mode=tap. Why not just do Kind=tap device? That under Linux the setup of both Tun and Tap devices happens via /dev/net/tun is just an implementation detail. The intention behind keeping Kind=tuntap is related to the driver. Kind - driver Mode- how it behaves . Of cource what you saying is correct implementation details but Kind is related to the driver. I fully agree with Marcel. We shouldn't expose users too directly to implementation details of the kernel. The fact that usually the Kind maps to the low-level driver doesn't mean we have to map it always 1:1. In this case it really makes more sense to map one driver (tuntap) into two different Kinds (tun + tap). We can abstract that Agreed . Lennart -- Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 1/8] (bugfix) undefined member, len, in struct kdbus_pool_slice
On 06/25/2014 11:13 AM, AKASHI Takahiro wrote: Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org --- pool.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pool.c b/pool.c index d896d9b..4267c54 100644 --- a/pool.c +++ b/pool.c @@ -623,7 +623,7 @@ void kdbus_pool_slice_flush(const struct kdbus_pool_slice *slice) #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1 struct address_space *mapping = slice-pool-f-f_mapping; pgoff_t first = slice-off PAGE_CACHE_SHIFT; - pgoff_t last = (slice-off + slice-len + + pgoff_t last = (slice-off + slice-size + Hmm, strange. This bug has been fixed upstream in May already. Which tree are you working against? Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 4/8] HACK0: allow meta information customizable
Hi, On 06/25/2014 11:13 AM, AKASHI Takahiro wrote: My ftrace log shows that kdbus_meta_append(), is one of dominant functions in sending a message, while the other is kdbus_conn_queue_alloc(). This patch adds an extra argument to kdbus_hello() utility function and allows us to explicitly specify meta information attached to a message for performance evaluation. Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org --- test/kdbus-util.c | 35 +-- test/kdbus-util.h |2 ++ 2 files changed, 23 insertions(+), 14 deletions(-) Note that the kernel features of kdbus are defined by the kernel code, not by the convenience wrappers for ioctl() that live in test/. As soon as you start to implement your own code using kdbus features, I'd strongly recommend you start over and implement your own low-level functions. The ioctl API is actually simple enough to do this. Same counts for patch #2 and #3 of this series. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tuntap device
On Wed, Jun 25, 2014 at 11:38 AM, Susant Sahani sus...@redhat.com wrote: On 06/25/2014 02:51 PM, Susant Sahani wrote: On 06/25/2014 02:21 PM, Lennart Poettering wrote: On Tue, 24.06.14 23:21, Susant Sahani (sus...@redhat.com) wrote: This patch introduces tuntap support to networkd. Example conf file : tuntap.netdev [NetDev] Name=tuntap-test Kind=tuntap [TUNTAP] Do we need to keep this section different as well ? for example [Tun] and [Tap] Yeah, I'd keep it separate (user should not know that it is the same internally). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 7/8] HACK3: minimize the range of D-Cache flush in ioctl(CMD_MSG_RECV)
On 06/25/2014 11:13 AM, AKASHI Takahiro wrote:
Current ioctl(CMD_MSG_RECV) contains an expensive cache operation. Even if
the data is quite small, it always executes D-Cache flush on a buffer
at minimum unit of one page in kdbus_conn_msg_install() /
kdbus_pool_slice_flush() .
In fact, flush_dcache_page() implementation is very expensive on ARM since
flushing is repeated at every cache line in a page. This may not be seen on
x86 because it doesn't have ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE on.
This patch replaces flush_dcache_page() by flush_kernel_vmap_range() with
the exact offset and size of slice. (Actually aligned to a cache-line size).
Signed-off-by: AKASHI Takahiro takahiro.aka...@linaro.org
---
pool.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/pool.c b/pool.c
index fcc54af..b723dd2 100644
--- a/pool.c
+++ b/pool.c
@@ -28,6 +28,13 @@
#include pool.h
#include util.h
+/*
+ * KDBUS_HACK3: Do dcache-flush only against the minimum range of slice
+ */
+#if KDBUS_HACK3
+#include asm/cacheflush.h
+#endif
+
/**
* struct kdbus_pool - the receiver's buffer
* @f: The backing shmem file
@@ -194,7 +201,13 @@ struct kdbus_pool_slice *kdbus_pool_slice_find(struct
kdbus_pool *pool,
int kdbus_pool_slice_alloc(struct kdbus_pool *pool,
struct kdbus_pool_slice **slice, size_t size)
{
+#if KDBUS_HACK3
+ /* FIXME: Assume that the cache line size is 128B. */
+#define DCACHE_ALIGN(size) ((size + 0x7f) ~0x7fUL)
+ size_t slice_size = DCACHE_ALIGN(size);
+#else
size_t slice_size = KDBUS_ALIGN8(size);
+#endif
struct rb_node *n, *found = NULL;
struct kdbus_pool_slice *s;
int ret = 0;
@@ -620,6 +633,9 @@ exit_free:
*/
void kdbus_pool_slice_flush(const struct kdbus_pool_slice *slice)
{
+#if KDBUS_HACK3
+ flush_kernel_vmap_range((void *)slice-off, slice-size);
+#else
This seems to be ok. Later this week, I can test this on some old ARM
boards that reproducibly showed cache aliasing.
Could you make this a real, non-hackish patch please that just removes
the old implementation and uses flush_kernel_vmap_range() instead,
without the KDBUS_HACK conditionals?
Thanks,
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd-wait-online and network.target
Hi, Commit 58e027023b47b32e42cf93dd4a629b869ee1ef25 'units: order network-online.target after network.target' added Before=network.target dependency to systemd-networkd-wait-online.service. Is that correct? If I understand the documentation correctly, then network.target should not be delayed. Maybe this was supposed to be Afternetwork.target? Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tuntap device
On 06/25/2014 03:28 PM, Tom Gundersen wrote: On Wed, Jun 25, 2014 at 11:38 AM, Susant Sahani sus...@redhat.com wrote: On 06/25/2014 02:51 PM, Susant Sahani wrote: On 06/25/2014 02:21 PM, Lennart Poettering wrote: On Tue, 24.06.14 23:21, Susant Sahani (sus...@redhat.com) wrote: This patch introduces tuntap support to networkd. Example conf file : tuntap.netdev [NetDev] Name=tuntap-test Kind=tuntap [TUNTAP] Do we need to keep this section different as well ? for example [Tun] and [Tap] Yeah, I'd keep it separate (user should not know that it is the same internally). Thanks Tom . -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 5/8] HACK1: optimize copy operations in kdbus_conn_queue_alloc()
On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro takahiro.aka...@linaro.org wrote: This function copies the reply message directly into receiver's buffer (pool slice). Looking into the implementation closely, however, there are multiple occurrences of copy operations, kdbus_pool_slice_copy(), which then executes costly prolog/epilog functions, say set_fs() and write_begin/write_end(), on each entry/exit. This patch uses a temporary buffer on the stack to compose a message and replace a costly function, kdbus_pool_slice_copy(), to memcpy() wherever possible, although I have to further confirm that this change is actually safe. +#if KDBUS_HACK1 + tmp = kmalloc(vec_data, GFP_KERNEL); You meant a malloced temporary buffer, not one allocated on the stack, right? We need to handle larger vectors than kmalloc can handle, that's why we copy directly to the receiver, and to avoid 2 copies. Did you find out what exactly in the call chain of our open-coded write shows up as expensive here? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 6/8] HACK2: blocking ioctl(CMD_MSG_RECV)
On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro takahiro.aka...@linaro.org wrote: In the current implementation, ioctl(CMD_MSG_RECV) returns immediately if no message has been queued, and so a service process has to wait by explicitly calling poll() system call. If such a process needs to wait only on a single connection, we can eliminate poll() system call by adding a synchronous attribute in receiving a message. Why is this useful in general? The peer can call RECV in a loop until EAGAIN without ever needing to call poll() as long as data is available. When there is no more message to handle, poll() is used to suspend the process, and only when it is idle anyway. Busy processes, the use-case we would optimize for, should not see a real benefit here? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] networkd: Introduce tun/tap device
This patch introduces TUN/TAP device creation support
to networkd.
Example conf to create a tap device:
file: tap.netdev
--
[NetDev]
Name=tap-test
Kind=tap
[Tap]
OneQueue=true
MultiQueue=true
PacketInfo=true
--
Modifications:
Added:
1. file networkd-tuntap.c
3. netdev kind NETDEV_KIND_TUN and NETDEV_KIND_TAP
2. Tun and Tap Sections and config params to parse
conf and gperf conf parameters
TODO:
1. Add user(uid) group(gid) parameters
---
Makefile.am | 1 +
src/network/networkd-netdev-gperf.gperf | 6 ++
src/network/networkd-netdev.c | 34 ---
src/network/networkd-tuntap.c | 101
src/network/networkd.h | 9 +++
5 files changed, 144 insertions(+), 7 deletions(-)
create mode 100644 src/network/networkd-tuntap.c
diff --git a/Makefile.am b/Makefile.am
index 4b292b2..165cfc3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4494,6 +4494,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-tunnel.c \
src/network/networkd-veth.c \
src/network/networkd-vxlan.c \
+ src/network/networkd-tuntap.c \
src/network/networkd-network.c \
src/network/networkd-address.c \
src/network/networkd-route.c \
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index 9125e1d..38133c8 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -38,3 +38,9 @@ VXLAN.Group, config_parse_tunnel_address,
0,
VXLAN.TOS, config_parse_unsigned, 0,
offsetof(NetDev, tos)
VXLAN.TTL, config_parse_unsigned, 0,
offsetof(NetDev, ttl)
VXLAN.MacLearning, config_parse_bool, 0,
offsetof(NetDev, learning)
+Tun.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tun.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tun.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
+Tap.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tap.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tap.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
diff --git a/src/network/networkd-netdev.c b/src/network/networkd-netdev.c
index dcf7596..644a1d0 100644
--- a/src/network/networkd-netdev.c
+++ b/src/network/networkd-netdev.c
@@ -41,7 +41,9 @@ static const char* const netdev_kind_table[_NETDEV_KIND_MAX]
= {
[NETDEV_KIND_GRE] = gre,
[NETDEV_KIND_SIT] = sit,
[NETDEV_KIND_VETH] = veth,
-[NETDEV_KIND_VTI] = vti
+[NETDEV_KIND_VTI] = vti,
+[NETDEV_KIND_TUN] = tun,
+[NETDEV_KIND_TAP] = tap
};
DEFINE_STRING_TABLE_LOOKUP(netdev_kind, NetDevKind);
@@ -221,6 +223,7 @@ static int netdev_enter_ready(NetDev *netdev) {
return 0;
}
+
static int netdev_create_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
NetDev *netdev = userdata;
int r;
@@ -521,11 +524,19 @@ int netdev_set_ifindex(NetDev *netdev, sd_rtnl_message
*message) {
return -EINVAL;
}
-if (!streq(kind, received_kind)) {
-log_error_netdev(netdev, Received newlink with wrong KIND %s,
- expected %s, received_kind, kind);
-netdev_enter_failed(netdev);
-return r;
+switch(netdev-kind) {
+case NETDEV_KIND_TUN:
+case NETDEV_KIND_TAP:
+break;
+default:
+if (!streq(kind, received_kind)) {
+log_error_netdev(netdev,
+ Received newlink with wrong KIND %s,
+ expected %s, received_kind, kind);
+netdev_enter_failed(netdev);
+return r;
+}
+break;
}
netdev-ifindex = ifindex;
@@ -617,9 +628,10 @@ static int netdev_load_one(Manager *manager, const char
*filename) {
netdev-vxlanid = VXLAN_VID_MAX + 1;
netdev-tunnel_pmtudisc = true;
netdev-learning = true;
+netdev-packet_info = true;
r = config_parse(NULL, filename, file,
- Match\0NetDev\0VLAN\0MACVLAN\0VXLAN\0Tunnel\0Peer\0,
+
Match\0NetDev\0VLAN\0MACVLAN\0VXLAN\0Tunnel\0Peer\0Tun\0Tap\0,
Re: [systemd-devel] Systemd stops
Hi, Finally I was able to get the my systemd running for multi-user mode, so I got login , password and then I could login and get prompt. I removed few services which were hindering the progress and included serial-getty.service in my multi-user mode, that did the trick. Since this is only the command shell prompt. I need the graphical unit also. So, I wanted to understand which services get executed in graphical unit? Is there any special care to be taken when you want graphical thing working? When I execute graphical unit, I get the same output as multi-user mode(i.e. it asks for login and password, but no GUI). I also wanted to know like there is also folder called user in systemd, how can I use its default.target file, since I already have one default.target file in system folder in systemd? Many in the group have helped me to reach this point. My sincere thanks to all. I would like some more help from you all. Thanks, Jay ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of softwar e viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com http://www.igate.com. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SIT tunnel does not work
On Sat, Jun 21, 2014 at 04:36:45PM +0530, Susant Sahani wrote: On 06/21/2014 02:47 PM, Tomasz Torcz wrote: Hi, I've tried to establish SIT tunnel to Hurricane Electric, using systemd v214. It does not work, device do not appear. I'm concerned about networkd discarding part of netlink messages, see below. Original instruction is provided by HE, rest is my shot at translating it into netdev (nb. manpage wasn't updated when tunnel features went in). The se.network file has conf problem. you need to put the interface name rather tunnel name like eth0/em1 Original instruction: - modprobe ipv6 ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local 109.107.25.67 ttl 255 ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local dev eth0 The local IP part comes directly from HE instructionpage. And it works, which is not the case for local dev eth0 version: $ ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local dev eth0 Error: an IP address is expected rather than dev $ rpm -qf /usr/sbin/ip iproute-3.15.0-1.fc21.x86_64 (adding dev works if I ALSO provide local ip part: ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local 109.107.25.67 ttl 255 dev eth0 ) ip link set he-ipv6 up ip addr add 2001:470:70:68d::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6 ip -f inet6 addr $ cat he.netdev --- [NetDev] Name=he Kind=sit [Tunnel] Local=109.107.25.67 Remote=216.66.80.162 $ cat he.network [Match] Name=he you need to supply the interface name here [Match] Name=em1 ==interface name After putting in interface name tunnel is still not created: # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd timestamp of '/etc/systemd/network' changed he: loaded sit sd-rtnl: discarding 20 bytes of incoming message could not add new link And no more lines mentioning neither tunnel nor he. -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: Don't require cgroups xattr support
Failure to mount cgroups with xattr should not be fatal
---
src/core/mount-setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 991bfdf..206f89a 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -94,7 +94,7 @@ static const MountPoint mount_table[] = {
{ tmpfs, /sys/fs/cgroup,tmpfs, mode=755,
MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
- NULL, MNT_FATAL|MNT_IN_CONTAINER },
+ NULL, MNT_IN_CONTAINER },
{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd, MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ pstore, /sys/fs/pstore,pstore, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rules: don't enable usb pm for Avocent devices
The Avocent KVM over IP devices doesn't work correctly with USB power
management enabled.
---
rules/42-usb-hid-pm.rules | 4
1 file changed, 4 deletions(-)
diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index c675b5b..4c300da 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -12,10 +12,6 @@ ACTION==add, SUBSYSTEM==usb, ATTR{product}==QEMU USB
Mouse, ATTR{serial}!=
ACTION==add, SUBSYSTEM==usb, ATTR{product}==QEMU USB Tablet,
ATTR{serial}!=1, TEST==power/control, ATTR{power/control}=auto
ACTION==add, SUBSYSTEM==usb, ATTR{product}==QEMU USB Keyboard,
ATTR{serial}!=1, TEST==power/control, ATTR{power/control}=auto
-# Catch-all for Avocent HID devices. Keyed off interface in order to only
-# trigger on HID class devices.
-ACTION==add, SUBSYSTEM==usb, ATTRS{idVendor}==0624,
ATTR{bInterfaceClass}==03, TEST==../power/control,
ATTR{../power/control}=auto
-
# Dell DRAC 4
ACTION==add, SUBSYSTEM==usb, ATTR{idVendor}==413c,
ATTR{idProduct}==2500, TEST==power/control, ATTR{power/control}=auto
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC/PATCH 3/3] coredump: compress core files
Op 25 jun. 2014, om 10:59 heeft Lennart Poettering lenn...@poettering.net het volgende geschreven: On Wed, 25.06.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Hi, a POC patch to compress coredumps after they are written. In my simple tests, this brings huge savings, because the compressed coredump can compress to ~5%. Unfortunately the core is first written uncompressed, then compressed by reading from disk and writing to the output file. This is ugly and slow, but I don't see a way around, if we want to get the backtrace without keeping everything in memory. I have the suspicion that there indeed is no other nice way for this... Hence looks good to me. 'coredumpctl gdb' is not implemented yet (the decompression part is missing). Hmm, we probably should add a coredump.conf option for this to turn on. Hmm, thinking about this, another idea might be to simply let the fs solve this by adding a high-level coredump.conf option to turn on FS_COMPR_FL for the coredump. This should do the right thing on btrfs (afaics at least), but of course would leave other file systems out. But then again, we develop the OS for tomorrow, not for yesterday here... But then again, maybe this stuff shouldn't be exclusive. Maybe a new coredump.conf option Compress=(filesystem|file|no) or so? (and maybe even Compress=auto, which does the right thing automatically, depending if the fs supports compression) After all, doing both file-level and filesystem-level compression makes little sense... The way btrfs currently does compression is to compress every (iirc 4k) block separately. Compressing the whole file at once will give a much bigger saving, especially when using xz. So btrfs/lzo will give you ~50% compression ratio vs the 5% mentioned above, a huge difference. I don't know how reiser4 or zfs tackle this. regards, Koen ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Cocci] systemd m4 library complex systemd example, and coccinelle conversion
On Wed, Jun 25, 2014 at 10:20:11AM +0200, Luis R. Rodriguez wrote: On Mon, Jun 23, 2014 at 03:19:30PM +0200, Lennart Poettering wrote: On Thu, 12.06.14 18:04, Luis R. Rodriguez (mcg...@do-not-panic.com) wrote: Hey folks, so I've been working on getting systemd support on xen for a bit now and thanks to the last suggestion about the launcher here on systemd-devel I think we're on the final stretch now. I'll be submitting a v6 PATCH series shortly which I think should be the last if not close to the last set we need. It turns out though that I ran into quite a few issues though, what I consider corner cases with systemd, and in order to help I've tried to put together a simple package example source code which exemplifies the complexities I found but more importantly provide the resolutions to those issues. At the same time xen also is a good example of a complex piece of software with multiple OS requirements and on the Linux font you may or may not want systemd, it also happened to use autoconf, but not automake, and in one iteration of patches I even worked on systemd support with the dynamic link loader (dlopen() and dlsym()). Adding proper support for systemd into xen turned out to be a bit of a mini project. In order to try to help other though I've generalized as much as I can the autotools functionality I wrote given I was unable to find a library to easily add systemd. I'd like your review of this piece of code and wanted to see if perhaps at least the LGPL m4 libraries might be welcomed. * src/m4/systemd.m4 - AX_ENABLE_SYSTEMD(): enables systemd by default and requires an explicit --disable-systemd option flag to configure if you want to disable systemd support. - AX_ALLOW_SYSTEMD(): systemd will be disabled by default and requires you to run configure with --enable-systemd to look for and enable systemd - AX_AVAILABLE_SYSTEMD(): systemd will be disabled by default but if your build system is detected to have systemd build libraries it will be enabled. You can always force disable with --disable-systemd - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. Hmm, so, I don't think systemd should really be treated differently from other pkg-config-enabled modules. What precisely does this add that pkg-config doesn't support? And wouldn't it be possible to improve pkg-config upstream instead? pkg-config is a helper to let you figure out what you have installed, flags required, etc. It doesn't do the autoconf voodoo dance which is simply a nightmare. Relying on pkg-config also assumes systemd has done the right job on all aspects of variables but as the m4 library annotates there a few areas where this could be enhanced so it tries to centralize this on an m4 library for userspace. Some libraries have their own detection macros, and they are more pain than it is worth. The reason is that the macro has to be available even if the library is not installed, which means that the macro has to be copied into the other project, or wrapped with a macro which detects that the macro is not available, before using it. Either option is unattractive and simply using pkg-config for everything turns out to be much cleaner. Of course this means that one has to provide special macros for pkg-config, but that's easier than adding custom support for every dependency. I don't think we want to support the dlsym() stuff in systemd directly. I mean, if people want to do things like that, that's fine, but I really doubt we should encourage that from upstream. Makes sense, its an option and the vodoo is done, if they inist the purpose of the funkd-systemd code is to say -- its done, and go at it, here's an example. Also note that pretty much any Linux distributions (modulo Gentoo/Slackware) uses systemd already or announced plans to do so, I am not sure it's worth really investing so much time in making systemd optional beyond the usual what pkg-config supports. It wasn't clear to me while learning about systemd so I was just agnostic to that. Its all there as options, people can choose. Lastly -- I was curious if anyone has looked into writing Coccinelle SmPL grammar rules to convert legacy init systems with systemd support. I suspect most unix daemons are rather simple and SmPL rules might be able to transform quite a bit of them. I don't expect Coccinelle might be able to catch the crazy daemons with corner cases as with xen, but you never know, coccinelle is always surprising me with its capabilities. Note that distribuitions like Fedora have
Re: [systemd-devel] [systemd-commits] man/systemctl.xml src/systemctl
On Wed, Jun 25, 2014 at 03:32:12AM -0700, Lennart Poettering wrote: man/systemctl.xml | 17 + src/systemctl/systemctl.c | 26 ++ 2 files changed, 43 insertions(+) + termcommandis-system-running/command/term + + listitem +paraChecks whether the system is running. This returns +success when the system is fully up and running, meaning +not in startup, shutdown or maintainance mode. Failure is +returned otherwise. In addition, the current state is +printed in a short string to standard output. Use +option--quiet/option to suppress output of this state +string./para + /listitem +/varlistentry is-system-running is very generic, without reading the documentation I would guess this to include the bootup phase. Maybe it should be renamed to something like is-bootup-finished or something. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] install: enable timesyncd by default
This treats it similarly to networkd, resolved and others and it matches what 90-systemd.preset does. --- Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile.am b/Makefile.am index 4b292b2..bfef1c3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4301,6 +4301,9 @@ rootlibexec_PROGRAMS += \ nodist_systemunit_DATA += \ units/systemd-timesyncd.service +GENERAL_ALIASES += \ + $(systemunitdir)/systemd-timesyncd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-timesyncd.service + EXTRA_DIST += \ units/systemd-timesyncd.service.in -- 2.0.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: use correct format string for UIDs
---
src/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/main.c b/src/core/main.c
index 6981e72..8ee12ef 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1548,7 +1548,7 @@ int main(int argc, char *argv[]) {
log_info(Running with unpopulated /etc.);
} else {
_cleanup_free_ char *t = uid_to_name(getuid());
-log_debug(PACKAGE_STRING running in user mode for user
PID_FMT/%s. ( SYSTEMD_FEATURES ),
+log_debug(PACKAGE_STRING running in user mode for user
UID_FMT/%s. ( SYSTEMD_FEATURES ),
getuid(), t);
}
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: Introduce tun/tap device
On Wed, Jun 25, 2014 at 04:13:39PM +0530, Susant Sahani wrote:
This patch introduces TUN/TAP device creation support
to networkd.
Example conf to create a tap device:
file: tap.netdev
--
[NetDev]
Name=tap-test
Kind=tap
[Tap]
OneQueue=true
MultiQueue=true
PacketInfo=true
--
Modifications:
Added:
1. file networkd-tuntap.c
3. netdev kind NETDEV_KIND_TUN and NETDEV_KIND_TAP
2. Tun and Tap Sections and config params to parse
conf and gperf conf parameters
TODO:
1. Add user(uid) group(gid) parameters
---
Makefile.am | 1 +
src/network/networkd-netdev-gperf.gperf | 6 ++
src/network/networkd-netdev.c | 34 ---
src/network/networkd-tuntap.c | 101
src/network/networkd.h | 9 +++
5 files changed, 144 insertions(+), 7 deletions(-)
create mode 100644 src/network/networkd-tuntap.c
diff --git a/Makefile.am b/Makefile.am
index 4b292b2..165cfc3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4494,6 +4494,7 @@ libsystemd_networkd_core_la_SOURCES = \
src/network/networkd-tunnel.c \
src/network/networkd-veth.c \
src/network/networkd-vxlan.c \
+ src/network/networkd-tuntap.c \
src/network/networkd-network.c \
src/network/networkd-address.c \
src/network/networkd-route.c \
diff --git a/src/network/networkd-netdev-gperf.gperf
b/src/network/networkd-netdev-gperf.gperf
index 9125e1d..38133c8 100644
--- a/src/network/networkd-netdev-gperf.gperf
+++ b/src/network/networkd-netdev-gperf.gperf
@@ -38,3 +38,9 @@ VXLAN.Group, config_parse_tunnel_address,
0,
VXLAN.TOS, config_parse_unsigned, 0,
offsetof(NetDev, tos)
VXLAN.TTL, config_parse_unsigned, 0,
offsetof(NetDev, ttl)
VXLAN.MacLearning, config_parse_bool, 0,
offsetof(NetDev, learning)
+Tun.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tun.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tun.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
+Tap.OneQueue,config_parse_bool, 0,
offsetof(NetDev, one_queue)
+Tap.MultiQueue, config_parse_bool, 0,
offsetof(NetDev, multi_queue)
+Tap.PacketInfo, config_parse_bool, 0,
offsetof(NetDev, packet_info)
diff --git a/src/network/networkd-netdev.c b/src/network/networkd-netdev.c
index dcf7596..644a1d0 100644
--- a/src/network/networkd-netdev.c
+++ b/src/network/networkd-netdev.c
@@ -41,7 +41,9 @@ static const char* const
netdev_kind_table[_NETDEV_KIND_MAX] = {
[NETDEV_KIND_GRE] = gre,
[NETDEV_KIND_SIT] = sit,
[NETDEV_KIND_VETH] = veth,
-[NETDEV_KIND_VTI] = vti
+[NETDEV_KIND_VTI] = vti,
+[NETDEV_KIND_TUN] = tun,
+[NETDEV_KIND_TAP] = tap - Maybe add a comma here, to makes future
patches simpler
};
DEFINE_STRING_TABLE_LOOKUP(netdev_kind, NetDevKind);
@@ -221,6 +223,7 @@ static int netdev_enter_ready(NetDev *netdev) {
return 0;
}
+
static int netdev_create_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void
*userdata) {
NetDev *netdev = userdata;
int r;
@@ -521,11 +524,19 @@ int netdev_set_ifindex(NetDev *netdev, sd_rtnl_message
*message) {
return -EINVAL;
}
-if (!streq(kind, received_kind)) {
-log_error_netdev(netdev, Received newlink with wrong KIND
%s,
- expected %s, received_kind, kind);
-netdev_enter_failed(netdev);
-return r;
+switch(netdev-kind) {
+case NETDEV_KIND_TUN:
+case NETDEV_KIND_TAP:
+break;
+default:
+if (!streq(kind, received_kind)) {
+log_error_netdev(netdev,
+ Received newlink with wrong KIND
%s,
+ expected %s, received_kind, kind);
+netdev_enter_failed(netdev);
+return r;
+}
+break;
}
netdev-ifindex = ifindex;
@@ -617,9 +628,10 @@ static int netdev_load_one(Manager *manager, const char
*filename) {
netdev-vxlanid = VXLAN_VID_MAX + 1;
netdev-tunnel_pmtudisc = true;
netdev-learning = true;
+netdev-packet_info = true;
r =
Re: [systemd-devel] [Cocci] systemd m4 library complex systemd example, and coccinelle conversion
On Wed, Jun 25, 2014 at 02:24:44PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jun 25, 2014 at 10:20:11AM +0200, Luis R. Rodriguez wrote: On Mon, Jun 23, 2014 at 03:19:30PM +0200, Lennart Poettering wrote: On Thu, 12.06.14 18:04, Luis R. Rodriguez (mcg...@do-not-panic.com) wrote: Hey folks, so I've been working on getting systemd support on xen for a bit now and thanks to the last suggestion about the launcher here on systemd-devel I think we're on the final stretch now. I'll be submitting a v6 PATCH series shortly which I think should be the last if not close to the last set we need. It turns out though that I ran into quite a few issues though, what I consider corner cases with systemd, and in order to help I've tried to put together a simple package example source code which exemplifies the complexities I found but more importantly provide the resolutions to those issues. At the same time xen also is a good example of a complex piece of software with multiple OS requirements and on the Linux font you may or may not want systemd, it also happened to use autoconf, but not automake, and in one iteration of patches I even worked on systemd support with the dynamic link loader (dlopen() and dlsym()). Adding proper support for systemd into xen turned out to be a bit of a mini project. In order to try to help other though I've generalized as much as I can the autotools functionality I wrote given I was unable to find a library to easily add systemd. I'd like your review of this piece of code and wanted to see if perhaps at least the LGPL m4 libraries might be welcomed. * src/m4/systemd.m4 - AX_ENABLE_SYSTEMD(): enables systemd by default and requires an explicit --disable-systemd option flag to configure if you want to disable systemd support. - AX_ALLOW_SYSTEMD(): systemd will be disabled by default and requires you to run configure with --enable-systemd to look for and enable systemd - AX_AVAILABLE_SYSTEMD(): systemd will be disabled by default but if your build system is detected to have systemd build libraries it will be enabled. You can always force disable with --disable-systemd - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. Hmm, so, I don't think systemd should really be treated differently from other pkg-config-enabled modules. What precisely does this add that pkg-config doesn't support? And wouldn't it be possible to improve pkg-config upstream instead? pkg-config is a helper to let you figure out what you have installed, flags required, etc. It doesn't do the autoconf voodoo dance which is simply a nightmare. Relying on pkg-config also assumes systemd has done the right job on all aspects of variables but as the m4 library annotates there a few areas where this could be enhanced so it tries to centralize this on an m4 library for userspace. Some libraries have their own detection macros, and they are more pain than it is worth. The reason is that the macro has to be available even if the library is not installed, which means that the macro has to be copied into the other project, or wrapped with a macro which detects that the macro is not available, before using it. Either option is unattractive and simply using pkg-config for everything turns out to be much cleaner. Of course this means that one has to provide special macros for pkg-config, but that's easier than adding custom support for every dependency. Good points -- that or autoconf gets replaced with something much more easier and modern that makes this seemless, but that certainly is a tangent. I don't think we want to support the dlsym() stuff in systemd directly. I mean, if people want to do things like that, that's fine, but I really doubt we should encourage that from upstream. Makes sense, its an option and the vodoo is done, if they inist the purpose of the funkd-systemd code is to say -- its done, and go at it, here's an example. Also note that pretty much any Linux distributions (modulo Gentoo/Slackware) uses systemd already or announced plans to do so, I am not sure it's worth really investing so much time in making systemd optional beyond the usual what pkg-config supports. It wasn't clear to me while learning about systemd so I was just agnostic to that. Its all there as options, people can choose. Lastly -- I was curious if anyone has looked into writing Coccinelle SmPL grammar rules to convert legacy init systems with systemd support. I suspect most unix
Re: [systemd-devel] [PATCH] rules: don't enable usb pm for Avocent devices
El 25/06/14 07:57, Tom Hirst escribió: The Avocent KVM over IP devices doesn't work correctly with USB power management enabled. Doesn't this also require kernel side blacklisting ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd m4 library complex systemd example, and coccinelle conversion
El 12/06/14 21:04, Luis R. Rodriguez escribió: - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. I urge you not to do that, this is unsuitable for distributions in a number of ways. - RPM does not handle this kind of dependencies. - Applications must only dlopen stuff they have control of, like..the X server loading its drivers, PHP loading its modules, apache loading mod_ssl.. etc.. dlopening system libraries like libsystemd-whatever is a no-no.. applications that do this constantly break, are a pain in the ass to maintain. I have been fighting with this madness for years. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd m4 library complex systemd example, and coccinelle conversion
On Wed, Jun 25, 2014 at 9:45 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 12/06/14 21:04, Luis R. Rodriguez escribió: - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. I urge you not to do that, this is unsuitable for distributions in a number of ways. - RPM does not handle this kind of dependencies. - Applications must only dlopen stuff they have control of, like..the X server loading its drivers, PHP loading its modules, apache loading mod_ssl.. etc.. dlopening system libraries like libsystemd-whatever is a no-no.. applications that do this constantly break, are a pain in the ass to maintain. I have been fighting with this madness for years. Thanks for the details! When I looked into this I didn't find any of the issues you have laid out, any chance you have pointers to a full fledged rant and technical details? I'd like to include it on my code and documentation :) Luis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] possible to run systemd-nspawn in a nested Xorg server?
Lennart Poettering lenn...@poettering.net schrieb: I wonder if it is possible to spawn systemd nspawn containers in a way that the login manager and GUI start up in a nested Xorg server so that I can run the container system in a window. I don't need the boot process in that window, just Xorg, when started, should open a nested Xorg window in my host system. Well, a container in many regards is just a networked host like any other. Depending on your login manager you can totally use it to manage remote displays. And yes, one of those remote machines might by an xnest running on your host. I just hoped there was already some standard way to do it. I will figure it out on my own then and report back. No problem. ;-) How to set that up is probably something to discuss with the login manager guys though... I'm currently a little bit confused what you mean by login manager... If you mean something like lightdm: I'm using that. But I don't want to switch back to my login manager to open a remote session into the container. I just want to run it from CLI from within my KDE session. If you mean systemd-logind - I think that is running for me. But I'm pretty sure that is not what you mean. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: don't enable usb pm for Avocent devices
El 25/06/14 07:57, Tom Hirst escribió: The Avocent KVM over IP devices doesn't work correctly with USB power management enabled. Doesn't this also require kernel side blacklisting ? I don't think so, as I understand it power/control defaults to on for everything except USB hubs and this rules file is a whitelist for devices that work with the auto setting ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd m4 library complex systemd example, and coccinelle conversion
El 25/06/14 13:00, Luis R. Rodriguez escribió: On Wed, Jun 25, 2014 at 9:45 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 12/06/14 21:04, Luis R. Rodriguez escribió: - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. I urge you not to do that, this is unsuitable for distributions in a number of ways. - RPM does not handle this kind of dependencies. - Applications must only dlopen stuff they have control of, like..the X server loading its drivers, PHP loading its modules, apache loading mod_ssl.. etc.. dlopening system libraries like libsystemd-whatever is a no-no.. applications that do this constantly break, are a pain in the ass to maintain. I have been fighting with this madness for years. Thanks for the details! When I looked into this I didn't find any of the issues you have laid out, any chance you have pointers to a full fledged rant and technical details? I'd like to include it on my code and documentation :) As usual, there is no documentation, this is my experience while dealing moutains of build failures and dependency issues in openSUSE. About the first point, rpm does not add dlopen() libraries as Requires, packagers must either add an explicit recommends or requires on a versioned shared library to the rpm spec, this fails in a number of ways: - Adding explicit Requires to libraries is forbidden by policy, rpmlint may warn and in some cases error out. - Even if you go ahead with that, there is no warranty that the library version will stay the same from product to product..requiring frequent adjustments, ifs and buts in the spec file. - Everytime the library major version changes, your code will fail, even in the case the library provides the same interface. _ Unless you use an specific glibc facility, DL_CALL_FCT() you cannot LD_PROFILE the application correctly.. There are other less obvious ways things can go wrong..such as obscure initialization order bugs when dependencies down the chain use GCC constructors/destructors but that's all in the top of my head for now. -- Cristian I don't know the key to success, but the key to failure is trying to please everybody. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
On Jun 24, 2014, at 8:46 PM, Andrey Borzenkov arvidj...@gmail.com wrote: В Tue, 24 Jun 2014 11:03:06 -0600 Chris Murphy li...@colorremedies.com пишет: On Jun 24, 2014, at 2:12 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Well, the initramfs should mount the rootfs readonly, and then it can read it's /etc/fstab (and the /forcefsck file) and determine if any further action should be taken before doing any kind of pivotroot type stuff to transition to the host OS. This should all be handled by your initramfs really. Not sure what systemd bits do that in a systemd+dracut combo tho', as not fiddled with it for a while! These are selective extractions, but are in order. I see no evidence the initramfs attempts to mount root. The first mount that happens is initiated by systemd. systemd can also be used in initrd^Wamfs. It has the whole set of units specifically for use in initrd. May be it is your case? I know the initramfs has a subset of systemd unit/service files, I don't know enough about it to investigate if dracut is actually putting the right ones in it or not. So I've just filed two bugs: RFE: honour rs.skipfsck in fstab-generator: which is the report about fs_passno for root being ignored; i.e. whether to honor fs_passno directly, or something else like systemd always initiating fsck for ext234, and never for xfs or btrfs. And I'm not sure if there's a valid debug use case to reverse those behaviors (i.e. never fsck for ext234, always fsck xfs btrfs to test the consequences) - not my expertise. https://bugzilla.redhat.com/show_bug.cgi?id=1098799 initrd: Failed to load configuration for systemd-fsck-root.service: which is now closed as notabug because it's an informational message only appearing with debug level logging https://bugzilla.redhat.com/show_bug.cgi?id=1107818 I think there's no catastrophe happening here, it's just a bit confusing that we have a place holder for whether fsck happens or not, and yet it's always happening even for file systems that don't need it. But it's also not a new problem, because many installers have been wrongly setting fs_passno to a non-zero value for xfs and btrfs for years. And now some installers wrongly not setting fs_passno non-zero for EFI System partitions (FAT) while also wrongly always mounting them rw by default. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Potential major bug in 214
Hi, folks. I'm about 90% sure there's a fairly significant bug in the systemd-sysv-generator that was introduced in 214. It's a bit complicated, and the full details are at https://bugs.freedesktop.org/show_bug.cgi?id=80537 . But the tl;dr summary is this: If there are any SysV initscripts in /etc/init.d that have: # Provides: $network or: # Should-Start: $network or: # Required-Start: $network they will wind up becoming dependencies of network-online.target, and so on any system where network-online.target is required by anything else (which is probably a lot of systems), they will be started at boot. Regardless of whether they're actually enabled so far as SysV is concerned. This has obvious potential unfortunate consequences...for instance, on a system with a forgotten /etc/init.d/telnet or /etc/init.d/vncserver or...you get the idea...lying around. I poked quite far into the bug and I *think* I more or less understand what's going on, but I wasn't able to come up with a sufficient fix for it. If folks could treat the report with a bit of urgency at least until it's established whether I'm correct or misunderstanding something, that'd be great. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Keyring service as a natural use-case for systemd?
Hi systemd community Last weeks I spent setting up identity caching at my Linux Arch machine. I wanted ssh-agent/gpg-agent functionality configured in a secure, clean and easy to manage way. Unfortunately more I learn about ssh-agent/gpg-agent/gnome keyring/envoy/Keychain more I dislike it. Both ssh-agent and gpg-agent are daemons that allow to keep private ssh and gpg keys in memory and avoid entering passphrase each time the key is used. I tried to create a systemd service file but it did not looks elegant (more about it later). Many people use wrapper that make ssh-agent/gpg-agent management easier (envoy[1], keychain [2]). The fact that there are such wrappers exist means that agents are either too complex or too hard to use. One of the weirdest decisions made by ssh/gpg developers is using environment variables to pass information about agent processes. Why don't they use some well-known location for the socket file like any other application does? Currently I need to run the *-agent daemon from user account, construct environment variables and propagate it to other processes such as Gnome and terminals started by sshd.service. It would be much nicer if *-agents created /run/user/$uid/gpg-agent.socket that any program can use. Ok, back to systemd service. I tried to create one based on https://github.com/zoqaeski/systemd-user-units/blob/master/user/gpg-agent.service. gpg-agent says itapplications is a drop-in replacement for ssh-agent but I found that gpg-agent does not work if I start it as systemd service - gpg-agent requires terminal where it can run pinentry application (the one where you enter ssh key passphrase). I end up with 2 user services - one for ssh-agent another for gpg-agent with additional scripting in ~/.bashrc that tries to construct GPG_ and SSH_ envvars. But I would love to see just one system daemon for all users without the additional configuration steps. All I expect to start the service is: sudo systemctl enable systemd-keyringd.socket After that 'ssh' 'gpg' should work without any configuration hustle. Here is more fun with these agents: - gdm login manager starts X session as a subshell of ssh-agent. Quoting 'man ssh-agent': The idea is that ssh-agent is started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.. I believe this is the way to export environment variables to child processes. - gnome3 has its own gnome-keyring-daemon [3] that reimplements ssh-agent/gpg-agent and makes one step towards using best practices plus provides UI client to manage the keyring. So my opinion about the keyring management/identity caching is that it is too weird/complicated. I would like to see someone who can make it more pleasant to use. And yes systemd community I am looking at you. Systemd already manages a bunch of user session information and I wonder if identity caching can be added here as well. What do you think? A good idea would be contact gnome-keyring developers and ask them to their their experience. But unlike gnome3 version of keyring daemon the systemd should be UI independent and work with gnome/kde/headless machines. [1] https://github.com/vodik/envoy [2] http://www.funtoo.org/Keychain [3] https://git.gnome.org/browse/gnome-keyring/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Potential major bug in 214
2014-06-25 23:18 GMT+02:00 Adam Williamson awill...@redhat.com: Hi, folks. I'm about 90% sure there's a fairly significant bug in the systemd-sysv-generator that was introduced in 214. It's a bit complicated, and the full details are at https://bugs.freedesktop.org/show_bug.cgi?id=80537 . But the tl;dr summary is this: If there are any SysV initscripts in /etc/init.d that have: # Provides: $network That should translate to Wants=network.target Before=network.target i.e., the service is provider for network.target. network.target itself is a passive unit. or: # Should-Start: $network IIRC with the old sysv support that simply translated to After=network.target. No Wants or Requires dependencies. or: # Required-Start: $network Same here. That simply translated to After=network.target they will wind up becoming dependencies of network-online.target, and so on any system where network-online.target is required by anything else (which is probably a lot of systems), they will be started at boot. Regardless of whether they're actually enabled so far as SysV is concerned. This has obvious potential unfortunate consequences...for instance, on a system with a forgotten /etc/init.d/telnet or /etc/init.d/vncserver or...you get the idea...lying around. I poked quite far into the bug and I *think* I more or less understand what's going on, but I wasn't able to come up with a sufficient fix for it. If folks could treat the report with a bit of urgency at least until it's established whether I'm correct or misunderstanding something, that'd be great. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Potential major bug in 214
On Thu, 2014-06-26 at 00:01 +0200, Michael Biebl wrote: If there are any SysV initscripts in /etc/init.d that have: # Provides: $network That should translate to Wants=network.target Before=network.target i.e., the service is provider for network.target. network.target itself is a passive unit. This particular case is somewhat different from the Should-Start and Required-Start cases, I think. We should probably consider it separately. In Fedora, I believe it only affects /etc/init.d/network , which winds up being wanted by network-online.target , which means it gets run even if NetworkManager is enabled. Which *does* seem wrong, but definitely not the same as the other case. It might even be best to split it into a different bug report. or: # Should-Start: $network IIRC with the old sysv support that simply translated to After=network.target. No Wants or Requires dependencies. or: # Required-Start: $network Same here. That simply translated to After=network.target So, I believe the sysv-generator code is basically *intended* to do what's advised in 'man systemd.special': network-online.target Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. i.e. if sysv service foo depends on $network, it wants to make the translated foo.service unit Want network-online.target (and be ordered After it - that part it gets right already). The problem I identified is that it gets this backwards, and winds up making network-online.target Want the service foo.service. You're questioning whether the generator's *intended* behaviour is the *optimal* behaviour, or whether the behaviour of the equivalent code in prior systemd versions was better. That seems like a slightly separate question. In answering it, the issue would be whether LSB's $network concept more closely matches systemd's network-online.target concept or its network.target concept. The LSB doc is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/facilname.html , and it says: $network basic networking support is available. Example: a server program could listen on a socket. So...discuss, I guess? I'm not going to venture an opinion. I'd say the highest priority thing here is that the current behaviour doesn't even seem to match the *intended* behaviour. But I guess if you were to decide that the generator's intention is wrong too and it should just do what the old systemd code did - After=network.target - then you could go straight from the current behaviour to that, and not worry about how to fix the code to do what it's currently trying to do... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd m4 library complex systemd example, and coccinelle conversion
On Wed, Jun 25, 2014 at 11:32 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 25/06/14 13:00, Luis R. Rodriguez escribió: On Wed, Jun 25, 2014 at 9:45 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 12/06/14 21:04, Luis R. Rodriguez escribió: - If you want to use the dynamic link loader you should use AX_AVAILABLE_SYSTEMD() but must then ensure to use -rdynamic -ldl when linking, if using automake autotools will deal with this for you, otherwise you must ensure this is in place on your Makefile. I urge you not to do that, this is unsuitable for distributions in a number of ways. - RPM does not handle this kind of dependencies. - Applications must only dlopen stuff they have control of, like..the X server loading its drivers, PHP loading its modules, apache loading mod_ssl.. etc.. dlopening system libraries like libsystemd-whatever is a no-no.. applications that do this constantly break, are a pain in the ass to maintain. I have been fighting with this madness for years. Thanks for the details! When I looked into this I didn't find any of the issues you have laid out, any chance you have pointers to a full fledged rant and technical details? I'd like to include it on my code and documentation :) As usual, there is no documentation, this is my experience while dealing moutains of build failures and dependency issues in openSUSE. A really nice public rant can help :) but so can editing the upstream dlopen() man pages: https://www.kernel.org/doc/man-pages/download.html If I would have found some good technical information on issues with dlopen() I wouldn't have even bothered, but I do think it can help prevent more folks from even considering it seriously. About the first point, rpm does not add dlopen() libraries as Requires, packagers must either add an explicit recommends or requires on a versioned shared library to the rpm spec, this fails in a number of ways: - Adding explicit Requires to libraries is forbidden by policy, rpmlint may warn and in some cases error out. - Even if you go ahead with that, there is no warranty that the library version will stay the same from product to product..requiring frequent adjustments, ifs and buts in the spec file. - Everytime the library major version changes, your code will fail, even in the case the library provides the same interface. _ Unless you use an specific glibc facility, DL_CALL_FCT() you cannot LD_PROFILE the application correctly.. There are other less obvious ways things can go wrong..such as obscure initialization order bugs when dependencies down the chain use GCC constructors/destructors but that's all in the top of my head for now. Fun :) yeah this would be good to have well documented somewhere. Luis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd stops
On Tue, 2014-06-24 at 03:10 +, Jay D Bhatt wrote: Hi Steev, You are almost correct. I use IMX6 board with 3.0.35 kernel ,but board is sabreauto. Can you guide how you made systemd work or settings needed on these board? Thanks, Jay You just need to make sure that all (possible) kernel config options are turned on that need to be. Most should be there, but there are some from 3.4+ that aren't. They only affect running systemd in usermode as far as I know. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add support for DHCP static route options in networkd
This adds support for DHCP options 33 and 121: Static Route and
Classless Static Route. To enable this feature, set UseRoutes=true
in .network file. Returned routes are added to the routing table.
---
man/systemd.network.xml | 7 ++
src/libsystemd-network/dhcp-lease-internal.h | 9 +-
src/libsystemd-network/dhcp-protocol.h | 1 +
src/libsystemd-network/network-internal.c| 88
src/libsystemd-network/network-internal.h| 7 ++
src/libsystemd-network/sd-dhcp-lease.c | 152 ++-
src/network/networkd-link.c | 83 ++-
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd.h | 1 +
src/network/test-network.c | 23
src/systemd/sd-dhcp-lease.h | 3 +-
11 files changed, 369 insertions(+), 6 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index efe6ce7..2105cb9 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -329,6 +329,13 @@
/listitem
/varlistentry
varlistentry
+
termvarnameUseRoutes=/varname/term
+listitem
+paraWhen true, the
static routes received from the DHCP server
+will be added to the
routing table./para
+/listitem
+/varlistentry
+varlistentry
termvarnameCriticalConnection=/varname/term
listitem
paraWhen true, the
connection will never be torn down even if the DHCP lease
diff --git a/src/libsystemd-network/dhcp-lease-internal.h
b/src/libsystemd-network/dhcp-lease-internal.h
index ff09583..d4675f3 100644
--- a/src/libsystemd-network/dhcp-lease-internal.h
+++ b/src/libsystemd-network/dhcp-lease-internal.h
@@ -32,6 +32,12 @@
#include sd-dhcp-client.h
+struct sd_dhcp_route {
+struct in_addr dst_addr;
+struct in_addr gw_addr;
+uint8_t dst_prefixlen;
+};
+
struct sd_dhcp_lease {
RefCount n_ref;
@@ -52,8 +58,9 @@ struct sd_dhcp_lease {
size_t ntp_size;
struct in_addr *policy_filter;
size_t policy_filter_size;
-struct in_addr *static_route;
+struct sd_dhcp_route *static_route;
size_t static_route_size;
+size_t static_route_allocated;
uint16_t boot_file_size;
uint16_t mdr;
uint16_t mtu;
diff --git a/src/libsystemd-network/dhcp-protocol.h
b/src/libsystemd-network/dhcp-protocol.h
index 4d87891..8cbd98e 100644
--- a/src/libsystemd-network/dhcp-protocol.h
+++ b/src/libsystemd-network/dhcp-protocol.h
@@ -132,5 +132,6 @@ enum {
DHCP_OPTION_RENEWAL_T1_TIME = 58,
DHCP_OPTION_REBINDING_T2_TIME = 59,
DHCP_OPTION_CLIENT_IDENTIFIER = 61,
+DHCP_OPTION_CLASSLESS_STATIC_ROUTE = 121,
DHCP_OPTION_END = 255,
};
diff --git a/src/libsystemd-network/network-internal.c
b/src/libsystemd-network/network-internal.c
index 97217c1..663ed7f 100644
--- a/src/libsystemd-network/network-internal.c
+++ b/src/libsystemd-network/network-internal.c
@@ -28,6 +28,7 @@
#include siphash24.h
#include libudev-private.h
#include network-internal.h
+#include dhcp-lease-internal.h
#include log.h
#include utf8.h
#include util.h
@@ -432,3 +433,90 @@ int deserialize_in6_addrs(struct in6_addr **ret,
size_t *ret_size, const char *s
return 0;
}
+
+void serialize_dhcp_routes(FILE *f, const char *key, struct
sd_dhcp_route *routes, size_t size) {
+unsigned i;
+
+assert(f);
+assert(key);
+assert(routes);
+assert(size);
+
+fprintf(f, %s=, key);
+
+for (i = 0; i size; i++)
+fprintf(f, %s/% PRIu8 ,%s%s, inet_ntoa(routes[i].dst_addr),
+routes[i].dst_prefixlen, inet_ntoa(routes[i].gw_addr),
+(i (size - 1)) ? : );
+
+fputs(\n, f);
+}
+
+int deserialize_dhcp_routes(struct sd_dhcp_route **ret, size_t
*ret_size, const char *string) {
+_cleanup_free_ struct sd_dhcp_route *routes = NULL;
+size_t size = 0;
+char *word, *state;
+size_t len;
+
+assert(ret);
+assert(ret_size);
+assert(string);
+
+FOREACH_WORD(word, len, string, state) {
+/* WORD FORMAT: dst_ip/dst_prefixlen,gw_ip */
+_cleanup_free_ char* entry;
+char *tok, *tok_end;
+struct sd_dhcp_route *new_routes;
+unsigned n;
+int r;
+
+new_routes = realloc(routes, (size + 1) *
sizeof(struct
Re: [systemd-devel] [RFC 6/8] HACK2: blocking ioctl(CMD_MSG_RECV)
2014-06-25 18:30 GMT+08:00 Kay Sievers k...@vrfy.org: On Wed, Jun 25, 2014 at 11:13 AM, AKASHI Takahiro takahiro.aka...@linaro.org wrote: In the current implementation, ioctl(CMD_MSG_RECV) returns immediately if no message has been queued, and so a service process has to wait by explicitly calling poll() system call. If such a process needs to wait only on a single connection, we can eliminate poll() system call by adding a synchronous attribute in receiving a message. Why is this useful in general? The peer can call RECV in a loop until EAGAIN without ever needing to call poll() as long as data is available. When there is no more message to handle, poll() is used to suspend the process, and only when it is idle anyway. Busy processes, the use-case we would optimize for, should not see a real benefit here? And library can simulate the sync calls by revc + poll anyway. There is no real benefit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd.net devwork
On 20.06.2014 20:21, Tom Gundersen wrote: On Fri, Jun 20, 2014 at 8:12 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 17.06.14 11:27, poma (pomidorabelis...@gmail.com) wrote: Hmm, can make this a proper git patch, i.e. with a useful commit msg we can just commit? That would make it a lot easier. TOm probably should review this, it's his area of expertise. Tom? (Oh, and while we don't strictly require it, we do prefer commiting stuff with real names. Unless you want to stay anonymous, it would be great if you could post patches at least with a realname. Thanks) Hi Poma, Thanks for the patch, and sorry for the delay. I'll try to get it reviewed and merged on Monday. At a quick glance, I'd drop the this has only been tested with ... line (not to say that more testing wouldn't be good, but I don't think the manpage is the place to ask for that). Also, if you could resubmit as suggested by Lennart hat would make my job a lot easier :) Cheers, Tom I want to run I want to hide I want to tear down the walls That hold me inside I want to reach out And touch the flame Where the streets have no name Thank you both for your patience. :) poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] SIT tunnel does not work
On 06/25/2014 04:50 PM, Tomasz Torcz wrote: On Sat, Jun 21, 2014 at 04:36:45PM +0530, Susant Sahani wrote: On 06/21/2014 02:47 PM, Tomasz Torcz wrote: Hi, I've tried to establish SIT tunnel to Hurricane Electric, using systemd v214. It does not work, device do not appear. I'm concerned about networkd discarding part of netlink messages, see below. Original instruction is provided by HE, rest is my shot at translating it into netdev (nb. manpage wasn't updated when tunnel features went in). The se.network file has conf problem. you need to put the interface name rather tunnel name like eth0/em1 Original instruction: - modprobe ipv6 ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local 109.107.25.67 ttl 255 ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local dev eth0 The local IP part comes directly from HE instructionpage. And it works, which is not the case for local dev eth0 version: $ ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local dev eth0 Error: an IP address is expected rather than dev The intention is that we need to the dev . Yes I missed providing the ipaddr. $ rpm -qf /usr/sbin/ip iproute-3.15.0-1.fc21.x86_64 (adding dev works if I ALSO provide local ip part: ip tunnel add he-ipv6 mode sit remote 216.66.80.162 local 109.107.25.67 ttl 255 dev eth0 ) ip link set he-ipv6 up ip addr add 2001:470:70:68d::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6 ip -f inet6 addr $ cat he.netdev --- [NetDev] Name=he Kind=sit [Tunnel] Local=109.107.25.67 Remote=216.66.80.162 $ cat he.network [Match] Name=he you need to supply the interface name here [Match] Name=em1 ==interface name After putting in interface name tunnel is still not created: could send do ip link output. # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd timestamp of '/etc/systemd/network' changed he: loaded sit sd-rtnl: discarding 20 bytes of incoming message could not add new link And no more lines mentioning neither tunnel nor he. -- Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Potential major bug in 214
On 2014-06-25 15:43, Thomas H.P. Andersen wrote: On Thu, Jun 26, 2014 at 12:01 AM, Michael Biebl mbi...@gmail.com wrote: 2014-06-25 23:18 GMT+02:00 Adam Williamson awill...@redhat.com: Hi, folks. I'm about 90% sure there's a fairly significant bug in the systemd-sysv-generator that was introduced in 214. It's a bit complicated, and the full details are at https://bugs.freedesktop.org/show_bug.cgi?id=80537 . But the tl;dr summary is this: I have push a patch that I think should correct this. 260ad50f5b4a9795032e3119c64f838a2d03370d The sysv parsing was moved to the generator in the following two commits. If the fix does not work then it should be possible to just revert those instead. 817e224bbce3ed157817961ef19c80a250845a05 95ed3294c632f5606327149f10cef1eb34422862 IIRC with the old sysv support that simply translated to After=network.target. No Wants or Requires dependencies. This was changed before I wrote the generator. http://cgit.freedesktop.org/systemd/systemd/commit/src/core/service.c?id=0404c609f399b2092a3de52eef9d75b0dc12e94ccontext=48 Sorry about all this. No problem at all. The fix looks good to me - I thought it would be something along those lines. I tested it and it does the intended thing for all the cases I found that were bad before. It should probably go to the 214-stable branch, if we didn't miss anything. Thanks a lot! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH resend] Add support for DHCP static route options in networkd
This adds support for DHCP options 33 and 121: Static Route and
Classless Static Route. To enable this feature, set UseRoutes=true
in .network file. Returned routes are added to the routing table.
---
man/systemd.network.xml | 7 ++
src/libsystemd-network/dhcp-lease-internal.h | 9 +-
src/libsystemd-network/dhcp-protocol.h | 1 +
src/libsystemd-network/network-internal.c| 88
src/libsystemd-network/network-internal.h| 7 ++
src/libsystemd-network/sd-dhcp-lease.c | 152 ++-
src/network/networkd-link.c | 83 ++-
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd.h | 1 +
src/network/test-network.c | 23
src/systemd/sd-dhcp-lease.h | 3 +-
11 files changed, 369 insertions(+), 6 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index efe6ce7..2105cb9 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -329,6 +329,13 @@
/listitem
/varlistentry
varlistentry
+
termvarnameUseRoutes=/varname/term
+listitem
+paraWhen true, the static
routes received from the DHCP server
+will be added to the routing
table./para
+/listitem
+/varlistentry
+varlistentry
termvarnameCriticalConnection=/varname/term
listitem
paraWhen true, the
connection will never be torn down even if the DHCP lease
diff --git a/src/libsystemd-network/dhcp-lease-internal.h
b/src/libsystemd-network/dhcp-lease-internal.h
index ff09583..d4675f3 100644
--- a/src/libsystemd-network/dhcp-lease-internal.h
+++ b/src/libsystemd-network/dhcp-lease-internal.h
@@ -32,6 +32,12 @@
#include sd-dhcp-client.h
+struct sd_dhcp_route {
+struct in_addr dst_addr;
+struct in_addr gw_addr;
+uint8_t dst_prefixlen;
+};
+
struct sd_dhcp_lease {
RefCount n_ref;
@@ -52,8 +58,9 @@ struct sd_dhcp_lease {
size_t ntp_size;
struct in_addr *policy_filter;
size_t policy_filter_size;
-struct in_addr *static_route;
+struct sd_dhcp_route *static_route;
size_t static_route_size;
+size_t static_route_allocated;
uint16_t boot_file_size;
uint16_t mdr;
uint16_t mtu;
diff --git a/src/libsystemd-network/dhcp-protocol.h
b/src/libsystemd-network/dhcp-protocol.h
index 4d87891..8cbd98e 100644
--- a/src/libsystemd-network/dhcp-protocol.h
+++ b/src/libsystemd-network/dhcp-protocol.h
@@ -132,5 +132,6 @@ enum {
DHCP_OPTION_RENEWAL_T1_TIME = 58,
DHCP_OPTION_REBINDING_T2_TIME = 59,
DHCP_OPTION_CLIENT_IDENTIFIER = 61,
+DHCP_OPTION_CLASSLESS_STATIC_ROUTE = 121,
DHCP_OPTION_END = 255,
};
diff --git a/src/libsystemd-network/network-internal.c
b/src/libsystemd-network/network-internal.c
index 97217c1..663ed7f 100644
--- a/src/libsystemd-network/network-internal.c
+++ b/src/libsystemd-network/network-internal.c
@@ -28,6 +28,7 @@
#include siphash24.h
#include libudev-private.h
#include network-internal.h
+#include dhcp-lease-internal.h
#include log.h
#include utf8.h
#include util.h
@@ -432,3 +433,90 @@ int deserialize_in6_addrs(struct in6_addr **ret, size_t
*ret_size, const char *s
return 0;
}
+
+void serialize_dhcp_routes(FILE *f, const char *key, struct sd_dhcp_route
*routes, size_t size) {
+unsigned i;
+
+assert(f);
+assert(key);
+assert(routes);
+assert(size);
+
+fprintf(f, %s=, key);
+
+for (i = 0; i size; i++)
+fprintf(f, %s/% PRIu8 ,%s%s, inet_ntoa(routes[i].dst_addr),
+routes[i].dst_prefixlen, inet_ntoa(routes[i].gw_addr),
+(i (size - 1)) ? : );
+
+fputs(\n, f);
+}
+
+int deserialize_dhcp_routes(struct sd_dhcp_route **ret, size_t *ret_size,
const char *string) {
+_cleanup_free_ struct sd_dhcp_route *routes = NULL;
+size_t size = 0;
+char *word, *state;
+size_t len;
+
+assert(ret);
+assert(ret_size);
+assert(string);
+
+FOREACH_WORD(word, len, string, state) {
+/* WORD FORMAT: dst_ip/dst_prefixlen,gw_ip */
+_cleanup_free_ char* entry;
+char *tok, *tok_end;
+struct sd_dhcp_route *new_routes;
+unsigned n;
+
Re: [systemd-devel] [PATCH] core: use correct format string for UIDs
On Wed, Jun 25, 2014 at 02:54:48PM +0200, Michał Bartoszkiewicz wrote:
---
src/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/main.c b/src/core/main.c
index 6981e72..8ee12ef 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1548,7 +1548,7 @@ int main(int argc, char *argv[]) {
log_info(Running with unpopulated /etc.);
} else {
_cleanup_free_ char *t = uid_to_name(getuid());
-log_debug(PACKAGE_STRING running in user mode for user
PID_FMT/%s. ( SYSTEMD_FEATURES ),
+log_debug(PACKAGE_STRING running in user mode for user
UID_FMT/%s. ( SYSTEMD_FEATURES ),
getuid(), t);
}
Applied.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Don't require cgroups xattr support
On Wed, Jun 25, 2014 at 11:45:45AM +, Tom Hirst wrote:
Failure to mount cgroups with xattr should not be fatal
---
src/core/mount-setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 991bfdf..206f89a 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -94,7 +94,7 @@ static const MountPoint mount_table[] = {
{ tmpfs, /sys/fs/cgroup,tmpfs,
mode=755, MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
- NULL, MNT_FATAL|MNT_IN_CONTAINER },
+ NULL, MNT_IN_CONTAINER },
{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd, MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ pstore, /sys/fs/pstore,pstore, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
Applied.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: enable timesyncd by default
On Wed, Jun 25, 2014 at 02:43:57PM +0200, Michael Olbrich wrote: This treats it similarly to networkd, resolved and others and it matches what 90-systemd.preset does. --- Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile.am b/Makefile.am index 4b292b2..bfef1c3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4301,6 +4301,9 @@ rootlibexec_PROGRAMS += \ nodist_systemunit_DATA += \ units/systemd-timesyncd.service +GENERAL_ALIASES += \ + $(systemunitdir)/systemd-timesyncd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-timesyncd.service + EXTRA_DIST += \ units/systemd-timesyncd.service.in Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
