Re: Portability of systemd [was: A few observations about systemd]

[Jonathan Nieder <jrnieder@gmail.com>]

Juliusz Chroboczek wrote:

> No, because that's not the case of systemd's core.  From what I've seen,
> most of the non-portable code in systemd's core is merely there for
> convenience.  For example, the %m printf descriptor is used extensively,
> which is just shorthand for strerror.  Similarly, openat is used in
> systemctl in order to implement a virtual cwd -- since systemctl is not
> multi-threaded, this is easily (albeit messily) simulated with either
> chdir or by manually concatenating absolute paths.

Now _that_ sort of thing is fixable.  Like so:

	#define printf compat_printf
	extern int compat_printf(const char *format, ...);

with compat_printf being a shim that handles %m.  See gnulib for some ---
perhaps too ambitious --- examples (printf and openat).

(By the way, I thought kfreebsd and hurd supported openat fine already.
It's even part of POSIX.  And %m is handled by glibc, not the kernel,
so not a problem for our ports.)

> Now I've certainly not read all of the systemd code, but the one
> exception that I've noticed is the use of cgroups.  While cgroups
> provide systemd with some of its coolest functionality (notably the
> ability to monitor SV initscripts, and the ability to reliably kill
> mis-behaving multi-process daemons), I'm not sure to what extent people
> think this functionality is central to systemd.

If we had forever to do it, I think the obvious thing would be to
provide the minimal cgroup functionality needed in the other kernels.
Alas, time is sometimes a hard thing to find.

Thanks and hope that's amusing.
Jonathan