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
I think that's an overstatement.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org