Portability of systemd [was: A few observations about systemd]
> It's not a simple portability problem, systemd relies on very complex
> Linux-specific stuff.
Well, having looked at the code, yes and no.
Yes, because systemd recodes the whole startup process in C.
Translating a lot of distritibution-specific shell code into C is not
going to be portable:
$ grep '^#.*TARGET' vconsole-setup.c
#ifdef TARGET_GENTOO
#ifdef TARGET_MANDRIVA
#if defined(TARGET_FEDORA) || defined(TARGET_MEEGO)
#if defined(TARGET_FEDORA) || defined(TARGET_MEEGO)
#elif defined(TARGET_SUSE)
#elif defined(TARGET_ARCH)
#elif defined(TARGET_FRUGALWARE)
#elif defined(TARGET_ALTLINUX)
#elif defined(TARGET_GENTOO)
#elif defined(TARGET_MANDRIVA)
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 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.
> I think implementing all the required stuff would be an effort
> comparable to implementing something like KMS or GEM or Gallium3D on
> FreeBSD.
I think that's an overstatement.
-- Juliusz
Reply to: