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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110718195017.ga6...@elie.gateway.2wire.net
