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
90
91
92
93
94
95
96
97
98
99
|
[[!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.
# bootstrap
A bootstrap dance happens between the disk translator, ext2fs and exec, one can
read [[the details on the system bootstrap|hurd/bootstrap]].
# disk translator
The disk translator contains the disk drivers used to access the root
filesystem. This is currently work in progress.
# 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 or the disk translator, 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]].
|
