>have you ever used s6 as process #1 on any other platform than Linux ?
>i bet you have not even tried to do so on any of the BSDs.
The BSDs are a different kind of beast: they're much more tightly
integrated than your run-of-the-mill Linux distro, and you can't
easily switch out one of the components of a BSD distro.
Replacing a BSD's init is absolutely doable: it just requires knowing
exactly what sequence of BSD-specific system calls is needed to
achieve a correct boot, and perform those in a s6-$os-init sequence,
either in stage 1 or stage 2. The problem is that it's not supposed
to be a stable API, so the BSDs are free to change it and the work
would need to be done again.
I don't think that it's worth prioritizing until there is real
traction for s6 which means a chance to get the change upstreamed - and
even then, because for many reasons, most of them good, the BSDs are
extremely reluctant to change if it comes from an outsider. Until it
can be upstreamed, bsd-with-s6-as-pid-1 can't be anything more than a
fun hack. Some people have toyed with it in the #s6 channel though.
Also, s6 works fine on the BSDs as a simple supervisor that doesn't
substitute itself to init, so you can already have its advantages
without the drawbacks. You can even have a strong supervision guarantee
if you use /etc/gettys to start the supervision tree.
>so why are you sticking to all this "POSIX-correctness" ?
>adding a few lines of code to support a specific platform (linux or any other
>unix) looks not like a big problem to me.
>sticking to POSIX features in the default case is a good way to
>achieve portability, that's right.
>but avoiding platform specific advantages at all costs seems
>pretty strange to me.
I value reproducible behaviour very much. When software behaves
differently depending on the platform is run on, it can quickly become
a maintenance nightmare. So unless a nonportable feature is *vital* to
get correct behaviour, I'd rather not use it.
For the SIGPWR and SIGWINCH thing, I made an exception because 1.
correctness is more important than anything else and 2. the patch was
absolutely trivial, so the increase in complexity due to having
architecture-dependent code paths was extremely minor. But the cost
needs to be evaluated on a case-by-case basis.
Note that I'm not avoiding platform-specific advantages when they can
achieve the same functionality. For instance, skalibs declares a
getpeereid() function, which isn't standardized in POSIX. The BSDs all
provide that function in their libc, so skalibs defers to the direct
libc implementation. Linux does not provide it, but has the SO_PEERCRED
option to getsockopt() that provides equivalent functionality. Solaris
doesn't have either of those things, but it has a getpeerucred()
function, which once again allows for some getpeereid() implementation.
>solaris, AIX and even OS X are all POSIX platforms, hence it
>would be interesting to see if s6 will work out of the box there
>(as process #1; handling SIGPWR may be a requirement here).
>i am sure it will since unlike systemd it is portable.
You are making a disingenuous argument. /sbin/init, aka the first
process that is launched by the kernel at boot time, is inherently
non-portable, because the exact API between the kernel and init has
not been standardized and every system does it differently. However,
once the non-portable sequence has been run, there's nothing that
prevents s6 from being able to run as process 1. The separation
between /sbin/init and cruising phase pid 1 is the very reason for
the existence of s6-linux-init (which does the nonportable things
for Linux, then execs into the portable s6-svscan), and the package
is named s6-linux-init because it is implied that there could easily
be s6-freebsd-init, s6-openbsd-init, s6-solaris-init, s6-macos-init
and others in the same vein if someone wanted to write them.
Again, I have not prioritized this work, but that doesn't mean it's
impossible, or even difficult. It just has low value at the moment.
The point is that the s6 package, implementing the supervision
mechanism, should remain portable, because there's no reason at all
it should be OS-dependent. All the nonportable details have been
confined to the s6-$os-init package.
>those platforms cannot be "POSIX-correct" if not.
>hence their kernels should be made "POSIX-correct" to run the
>"POSIX-correct" s6 unchanged as process #1.
>
>so who has to adapt, s6 or those kernels ?
*You* have to adapt. You need to stop making false dichotomies and
fallacious arguments, because they don't work here. :P
--
Laurent
Received on Mon Feb 24 2020 - 00:33:34 UTC