From 1bfba3b0be32306b078f5ee527b864e758b2c77b Mon Sep 17 00:00:00 2001 From: Laurent Bercot Date: Fri, 26 Apr 2019 15:52:54 +0000 Subject: Make a single hpr. Full doc, first draft. --- doc/why.html | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 doc/why.html (limited to 'doc/why.html') diff --git a/doc/why.html b/doc/why.html new file mode 100644 index 0000000..2c200c5 --- /dev/null +++ b/doc/why.html @@ -0,0 +1,139 @@ + + + + + + s6-linux-init: why? + + + + + + +

+s6-linux-init
+Software
+skarnet.org +

+ +

Why s6-linux-init ?

+ +

The s6 software stack

+ +

+ The s6 ecosystem is made of several parts, which are mainly the following: +

+ + + +

Providing a complete init system

+ +

+ As explained in +this +presentation">, an init system is made of four parts: +

+ +
    +
  1. /sbin/init: the first userspace program that is run by the +kernel at boot time (not counting an initramfs).
    2. +
  2. pid 1: the program that will run as process 1 for most of +the lifetime of the machine. This is not necessarily the same executable +as /sbin/init, because /sbin/init can exec into something +else.
    3. +
  3. a process supervisor.
    4. +
  4. a service manager.
    5. +
+ +

+ The s6 package obviously provides +part 3. It also provides part 2, because +s6-svscan is suitable +as being pid 1 after some small setup is performed. +

+ +

+ Part 4, service management, can be provided in a variety of ways. The +s6-rc service manager is the +natural complement to the s6 process supervisor, but it is not the only +possibility. The +anopa package also provides a +service manager designed to work with s6. And, at the expense of +tight integration with the supervisor, it is possible to run a "traditional" +service manager, such as sysv-rc or OpenRC, with an s6-based init system. +This flexibility is possible because service management is one layer above +the mechanisms of init and process supervision. +

+ +

+ Remains part 1. And that's where s6-linux-init enters the picture. +

+ +

Portability

+ +

+ Part 1 of an init system, the /sbin/init program, has been purposefully +omitted from the main s6 package, for a simple reason: s6 aims to be portable +to any flavor of Unix, and it is impossible to implement /sbin/init +in a portable way. +

+ +

+ For instance, to do its job, +s6-svscan needs +a writable directory. Such a directory may not be available at boot time, +before mounting filesystems, because the root filesystem may be read-only. +So, at least one writable filesystem (typically a RAM-backed one) must be +mounted before s6-svscan can be executed and be pid 1. And mounting a +filesystem is a non-portable operation. +

+ +

Complexity

+ +

+ Moreover, the sequence of operations that a /sbin/init program +needs to perform before executing into s6-svscan is a bit +tricky. It can be scripted, but it's not easy, and since it's so early +in the lifetime of the machine, there's no safety net at all (the +supervision tree itself, and the early getty, are supposed to be the +safety net! and they're not there yet). So it's better to automate +these operations. +

+ +

Conclusion

+ +

+ s6-linux-init aims to provide a fully functional /sbin/init +program that executes into an s6 supervision tree with all the necessary +support services already in place, as well as the corresponding shutdown +commands. It also aims to be flexible enough to accommodate various needs +and be compatible with any user-chosen service manager. +

+ +

+As usual, it is about mechanism, not policy. +

+ + + -- cgit v1.3.1