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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13
Contributions by:
Michael I. Bushnell <mib@gnu.org>
Len Tower <tower@gnu.org>
Trent Fisher <trent@gnurd.uu.pdx.edu>
jlr@usoft.spb.su
Remy Card <Remy.Card@masi.ibp.fr>
Louis-Dominique Dubeau <hallu@info.polymtl.ca>
Original Document by: Derek Upham <upham@cs.ubc.ca>
==============================
Contents:
Q0. Where can I get the Unofficial GNU Hurd FAQ?
Q2. Where can I get a copy?
Q3. Why bother writing a new OS when we have Linux and 386/BSD?
Q4. What's all this about Mach 3.0 (and Mach 4.0)?
Q5. Where can I find more information?
Q7. What sort of machines will run Hurd in the future?
Q8. What is the current development status?
Q9. What sort of system would we have if the Hurd was bootable today?
==============================
Q0. Where can I get the Unofficial GNU Hurd FAQ?
The Unofficial Hurd FAQ (what you are reading now) is occasionally
posted to the USENET newsgroup, gnu.misc.discuss. It is also
available from
http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt (Broken Link ?)
If you don't have WWW access, you may send mail to me, Gordon
Matzigkeit <gord@enci.ucalgary.ca> with a subject line that reads:
Subject: send hurd-faq
You should receive a PGP-signed copy of the current version of this
document in a matter of minutes.
Q2. Where can I get a copy?
To put it simply, you can't. It is still under development (by
Michael Bushnell, Roland McGrath and Miles Bader). It is almost, but
not quite, at the point where you can do real work on it. Keep your
fingers crossed.
Some people have actually bootstrapped it, but the work is not easy,
and the current snapshot won't work until a new multiserver boot
mechanism is made.
If you *really* want to try it, beware that it is still pre-alpha
code, and that it will likely crash on you. See Trent Fisher's Hurd
pages (under question 5) for the latest information.
Q3. Why bother writing a new OS when we have Linux and 386/BSD?
For one thing, Linux and BSD don't scale well. Hardware designers are
shifting more and more toward multiprocessor machines for performance,
and standard Unix kernels do not provide much multiprocessor support.
The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel
[[1]] from CMU. Mach was designed precisely for multiprocessing
machines, so its portability should carry over nicely to the Hurd.
In addition, the Hurd will be considerably more flexible and robust
than generic Unix. Wherever possible, Unix kernel features have been
moved into unprivileged space. Once there, anyone who desires can
develop custom replacements for them. Users will be able to write and
use their own file systems, their own `exec' servers, or their own
network protocols if they like, all without disturbing other users.
The Linux kernel has now been modified to allow user-level file
systems, so there is proof that people will actually use features such
as these. It will be much easier to do under the Hurd, however,
because the Hurd is almost entirely run in user space and because the
various servers are designed for this sort of modification.
Q4. What's all this about Mach 3.0 (and Mach 4.0)?
As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon
University. A more descriptive term might be a greatest-common-factor
kernel, since it provides facilities common to all ``real'' operating
systems, such as memory management, inter-process communication,
processes, and a bunch of other stuff. Unfortunately, the system
calls used to access these facilities are only vaguely related to the
familiar and cherished Unix system calls. There are no "fork",
"wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All
this makes it rather difficult to, say, port GNU Emacs to a Mach box.
The trick is, of course, to write an emulation library. Unix programs
can then use (what they think are) POSIX system calls and facilities
while they are really using Mach system calls and facilities.
The simplest way of going about this is to take an ordinary Unix
kernel, open it up, and rip out all the machine-specific guts; any
time the Unix kernel talks to the machine, replace the code with calls
to the Mach micro-kernel. Run this fake kernel on a Mach machine and
you end up with something that looks and acts just like Unix (even to
GNU Emacs). Note that the Unix kernel we have implemented is just one
Really Big Mach program (called a single-server).
The Hurd, on the other hand, breaks the giant Unix kernel down into
various Mach programs running as daemons. Working in concert with
facilities placed in the C library, these daemons provide all of the
POSIX system-calls and features; from the outside they look just like
a standard Unix kernel. This means that, for practical purposes,
anything that you can port to Linux will also port to the Hurd.
Of course, if a user wishes to run his own daemons, he can do that as
well....
Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at
the University of Utah. They are working on another free operating
system, and part of it includes an enhanced, more flexible version of
Mach. The Hurd has moved to Mach 4.0, which is good, because it is a
lot easier to build than 3.0 was.
You can find more information on Mach by browsing the Hurd pages given
in the next answer, or by looking at the Project Mach and Flux
homepages at:
Carnegie Mellon University (for Mach versions before 4.0):
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
the University of Utah (for Mach 4.0):
http://www.cs.utah.edu/projects/flux/mach4/html/
==============================
Footnotes:
[[1]] Yes, I know that ``micro-kernel'' is about as apt a description
as ``Reduced Instruction Set Chip'', but we're stuck with it.
|
