This provides an quick overview of how the GNU/Hurd system starts, and thus how it is structured.


The GNU/Hurd system uses multiboot, and thus usually booted from grub, which loads into memory the GNU Mach kernel, the ext2fs server (see later), and the exec server (see later). It then gives hand to GNU Mach, passing ext2fs and exec as payloads.

GNU Mach

GNU Mach initializes a basic console, and tasks, memory management and interprocess communication (details can be read on boot trace). It also initializes drivers for disk. It then creates two tasks for the ext2fs and exec servers.


ext2fs is given as a parameter the name of the device of the root filesystem. It opens it through the GNU Mach disk driver, and mounts the filesystem found on it. When it is ready, it can start booting the system by starting the "startup", "proc", and "auth" servers. It does so by using the "exec" server already loaded by GNU Mach. We then have a posixish environment, ext2fs gives hand to "startup".


"exec" handles loading binaries into processes. Details are available in Thomas' overview.


Proc knows about processes: what pid they have, passing signals, managing tty sessions, etc. Details are available in Thomas' overview and Marcus' presentation.


Auth knows about identities: uid, gid, etc. Details are available in Thomas' overview and Marcus' presentation.


"startup" is the unixish system starting point: it basically runs /sbin/init, at which point we end up with the standard Unix boot up.

netdde / pfinet

At some point of the boot process, networking will have to be configured. This is done by starting "pfinet", the TCP/IP stack, from /servers/socket/2, which itself starts the network device driver server, "netdde", from /dev/netdde.


Normal processes use glibc to interact with the system. Depending on the kind of call, glibc will perform RPCs with the various servers mentioned above: opening files will trigger RPCs with ext2fs, calling getpid() and such will trigger RPCs with proc, calling getuid() and such will trigger RPCs with auth, opening a network socket will trigger RPCs with pfinet. Details are available in the RPC page

One can read the details how reading a file happens.

how translators get started

There are three ways translators get started:

  • exec, startup, proc, auth are explictly started during the boot as explained above.
  • some file of the filesystem have a passive translator record, i.e. it is recorded in the filesystem that when you open the file, it actually starts a translator which provides the content. For instance, /dev/null is actually a translator which eats your data and produces no data.
  • one can manually start a translator and bind it on a file of the filesystem. It will stay there until getting killed or the system is restarted. For instance, one may want to temporarily mount an ISO image.

Details are available in Marcus' presentation.