> 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 -- 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/8739i3buad.fsf...@trurl.pps.jussieu.fr
