On Mon, Jul 18, 2011 at 3:19 PM, Juliusz Chroboczek <jch@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/8739i3buad.fsf_-_@trurl.pps.jussieu.fr
>
>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAE2SPAa=hcaq9Lg+o_XCcK7ncGaqxy2SitfOmqHsd5Xgx+gkG Q@mail.gmail.com">http://lists.debian.org/CAE2SPAa=hcaq9Lg+o_XCcK7ncGaqxy2SitfOmqHsd5Xgx+gkG Q@mail.gmail.com

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110718195017.GA6566@elie.gateway.2wire.net">http ://lists.debian.org/20110718195017.GA6566@elie.gateway.2wire.net

On Mon, Jul 18, 2011 at 02:50:17PM -0500, Jonathan Nieder wrote:
> (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.)

I know the FreeBSD kernel has supported openat(2) since 8.0, but I don't
know if the kFreeBSD glibc has it implemented. If not, it's very likely
trivial to accomplish.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187