On Mon, Jul 18, 2011 at 3:19 PM, Juliusz Chroboczek <j...@pps.jussieu.fr> wrote: >> 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.
see gnulib portable to most unix > 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. See also gnulib but could fail if mode change behalf (see also gnulib). Could be emulated using fork then sending fd by socket > > 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. BSD jail >> 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 > > -- 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/CAE2SPAa=hcaq9lg+o_xcck7ncgaqxy2sitfomqhsd5xgx+g...@mail.gmail.com
