[Soc-coordination] Weekly report (6th week) - Debian GNU/Hurd Debianish initialization

[4winter at informatik.uni-hamburg.de]

.. link: 
.. description: 
.. tags: gsoc, debian, hurd
.. date: 2013/07/26 21:20:34
.. title: Bootstrapping the Hurd
.. slug: bootstrapping-the-hurd

Due to popular demand this weeks report contains another awesome ascii
screenshot. I added some lines to `/etc/hurd/runsystem.sysv` to
inspect the environment very early in the boot process::

  start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec init proc auth
  [...]
  + echo my pid is 1
  my pid is 1
  + ps Ax
  + head
  USER       PID TT STAT     TIME COMMAND
  -            0  ? R<mo  0:00.01 /hurd/proc
  root         1  - Sslow 0:00.02 /bin/sh /etc/hurd/runsystem
  -            2  - Sp    0:00.00 /hurd/init root=device:hd0s1 console=com0
  -            3  ? D<p   0:00.01 root=device:hd0s1 console=com0
  -            4  - S<o   0:00.18 ext2fs --readonly --multiboot-command-line=root
  -            5  - S<o   0:00.02 /hurd/exec
  -            6  - S<o   0:00.00 /hurd/auth
  root         7  - S<o   0:00.04 /hurd/term /dev/console device console
  root         8  - S<o   0:00.00 /hurd/pflocal
  + pstree -p
  sh(1)-+-init(2)-+-auth(6)
        |         `-ext2fs(4)-+-exec(5)
        |                     |-pflocal(8)
        |                     |-procfs(12)
        |                     `-term(7)
        |-pstree(11)
        `-root=device:hd0s1(3)

Those who are familiar with the Hurd might note that
`/etc/hurd/runsystem.sysv` runs as PID 1. At the end of this script
`/sbin/init` is exec(2)uted, so `sysvinit gets run as PID 1
</gsoc/#sysvinitrelatedissues>`_. This is the result of a fairly small
`patch series
<http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00245.html>`_. It
still took me like two days to come up with it since bootstrapping a
Hurd system (or any microkernel OS, or like bootstrapping in general)
is complicated.

If you look at the screenshot above you will note the `/hurd/pflocal`
process running with PID 8. This is the server providing `pipe(2)s`
and Unix sockets. Before that server is started, one cannot use pipes
to connect two processes with pipes like I did with `ps` and `head` (I
actually lied a little here, because the way Debian/Hurd is set up,
the pflocal server is started on demand courtesy of a Hurd feature
called "passive translators", very similar to what the cool kids call
"socket activation" today).

Process 0 is the `/hurd/proc` server. It maps Mach tasks to the
concept of Unix processes. Before that server is started, the notion
of a process does not even exist. Pid 4 is the root
filesystem. Without that, no other server can be read from the
disk. But if the root filesystem is to be started first, it cannot be
registered as a Unix process at the proc server, because that has not
been started yet.

So the first few processes are started in a weird way and order, and
since they need to talk to each other, they need to register at each
other. No Unix concepts exist yet, only Mach concepts like tasks and
messages can be used. The boot sequence is roughly this (the numbers
in parenthesis are the PIDs):

1. Grub loads GNU Mach(3), the statically linked root filesystem
   translator (4) and the `/hurd/exec` (5) server (the exec server loads
   executables into Mach tasks, implementing most parts of execve(2)).
2. The rootfs translator is started.
3. The rootfs initiates the Hurd server bootstrap by starting
   `/hurd/exec` and `/hurd/init` (2).
4. `/hurd/init` starts `/hurd/proc` (0) and `/hurd/auth` (6).
5. The translators perform several rendezvouses to introduce
   themselves to each other.
6. The proc servers state with respect to the already running
   processes is fixed.
7. `/hurd/init` starts `/etc/hurd/runsystem` (1) which starts the
   pager (that pages out memory to disk) and later execs `/sbin/init`.
8. From this point on the initialization of Debian/Hurd is no
   different from Debian/Linux.

Besides the pid one issue I spent my time on:

* A prototypical patch for the other `sysvinit related issue
  </gsoc/#sysvinitrelatedissues>`_, `/sbin/killall5` wreaking havoc on
  a Hurd system:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00226.html

* I updated my patch series binding the mtab translator to
  `/proc/mounts`:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00216.html

* I updated my patch series for daemonizing support for
  `console-client`:
  http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00246.html

Next week I hope to fully address the `killall5` issue and to clean
up, polish and submit my patch series for `sysvinit`. I will then
revise my mtab translator prototype which is currently in its third
iteration. As always, if there is time left, I will look at the
`network related issues </gsoc/#networkrelatedissues>`_.