summaryrefslogtreecommitdiff
path: root/overview.mdwn
blob: 11d9382b047c0ada39631d46b1695e09d603861f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
[[!meta copyright="Copyright © 2015 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

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

# Grub

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
[[microkernel/mach/gnumach/boot_trace]]).  It also initializes drivers for
disk. It then creates two tasks for the ext2fs and exec servers.

# ext2fs

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

"exec" handles loading binaries into processes.  Details are available in
[[Thomas' overview|/hurd-paper#exec]].

# proc

Proc knows about processes: what pid they have, passing signals, managing tty
sessions, etc.  Details are available in [[Thomas' overview|/hurd-paper#proc]]
and [[Marcus' presentation|/hurd-talk#pro]].

# auth

Auth knows about identities: uid, gid, etc.  Details are available in
[[Thomas' overview|/hurd-paper#auth]] and
[[Marcus' presentation|/hurd-talk#aut]].

# startup

"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.

# everydaylife

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|/hurd/rpc]]

One can read the [[details how reading a file happens|hurd/io_path]].

# 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|/hurd-talk#act]].