27 |
kernel = /boot/laden |
kernel = /boot/laden |
28 |
module = /boot/ia32-kernel |
module = /boot/ia32-kernel |
29 |
module = /boot/sigma0 |
module = /boot/sigma0 |
30 |
module = /boot/rootserver |
module = /boot/wortel |
31 |
module = ...more servers... |
module = /boot/physmem |
32 |
|
module = /boot/task |
33 |
|
module = /boot/deva |
34 |
|
module = /boot/deva-drivers |
35 |
|
module = /boot/rootfs |
36 |
\end{verbatim} |
\end{verbatim} |
37 |
|
|
|
\begin{comment} |
|
|
The name of the rootserver and the further modules are not specified |
|
|
yet. |
|
|
\end{comment} |
|
|
|
|
38 |
GNU GRUB loads the binary image files into memory and jumps to the |
GNU GRUB loads the binary image files into memory and jumps to the |
39 |
entry point of \texttt{laden}. |
entry point of \texttt{laden}. |
40 |
|
|
155 |
The thread ID of $\sigma_1$ is (\verb/UserBase/ + 1, 1). |
The thread ID of $\sigma_1$ is (\verb/UserBase/ + 1, 1). |
156 |
|
|
157 |
|
|
158 |
\section{The rootserver} |
\section{The rootserver wortel} |
159 |
\label{rootserver} |
\label{rootserver} |
160 |
|
\label{wortel} |
161 |
|
|
162 |
The rootserver is the only task in the system which threads can |
The rootserver that L4 started is the only task in the system which |
163 |
perform privileged system calls. So the rootserver must provide |
threads can perform privileged system calls. So the rootserver must |
164 |
wrappers for the system calls to other unprivileged system tasks. |
provide wrappers for the system calls to other unprivileged system |
165 |
|
tasks. |
166 |
|
|
167 |
\begin{comment} |
\begin{comment} |
168 |
For this, a simple authentication scheme is required. The |
For this, a simple authentication scheme is required. The |
177 |
priority. |
priority. |
178 |
\end{comment} |
\end{comment} |
179 |
|
|
180 |
|
Our rootserver is called wortel, and also bootstraps the operating |
181 |
|
system. Wortel thus acts as a simple manager OS and as a bootloader |
182 |
|
program. |
183 |
|
|
184 |
|
\begin{comment} |
185 |
|
Ideally, there would be a real manager OS on top of L4 in which you |
186 |
|
can run different sand-boxed operating systems. Wortel implements |
187 |
|
only some rudimentary features such a system would provide: Access |
188 |
|
to the system memory and execution of privileged L4 system calls. |
189 |
|
|
190 |
|
If you had such a real manager OS, then this manager OS would start |
191 |
|
a bootloader to boot up a sand-boxed operating system. For |
192 |
|
simplicity, wortel currently implements such a bootloader for the |
193 |
|
Hurd system. Eventually, the code should be split to allow both |
194 |
|
components to develop independently. |
195 |
|
\end{comment} |
196 |
|
|
197 |
The rootserver has the following initial state: |
The rootserver has the following initial state: |
198 |
|
|
199 |
\begin{itemize} |
\begin{itemize} |
236 |
\end{comment} |
\end{comment} |
237 |
|
|
238 |
|
|
239 |
\section{The physical memory server} |
\section{The physical memory server physmem} |
240 |
|
|
241 |
To be written. |
The physical memory server is the first component of the actual Hurd |
242 |
|
system that is started (wortel serves as a manager OS in the |
243 |
|
background, and its presence is of no relevance to Hurd programs other |
244 |
|
than the fundamental core servers described in this chapter). It |
245 |
|
provides memory management routines that allow tasks in the Hurd |
246 |
|
system to be self-paged. |
247 |
|
|
248 |
|
The rootserver moves the physical memory server executable image to |
249 |
|
its ELF load address (and initializes the BSS section to zero), |
250 |
|
creates a new address space and several threads in this address space, |
251 |
|
starts the first thread and then maps all the fpages covering the |
252 |
|
executable image 1:1 into the address space at the first pagefault |
253 |
|
(the fpage on which the thread faulted is mapped last - this makes the |
254 |
|
thread fault repeatedly until the whole image is mapped). |
255 |
|
|
256 |
\begin{comment} |
\begin{comment} |
257 |
In fact, I already have some ideas. Here they are: |
Wortel should follow the \texttt{exec()} protocol to startup the new |
258 |
|
task as closely as possible. However, there is little that wortel |
259 |
|
can provide to physmem in this terms. |
260 |
|
\end{comment} |
261 |
|
|
262 |
|
So, the physical memory server runs on mapped memory in its own |
263 |
|
address space, but the virtual addresses of its executable image |
264 |
|
coincede with the physical addresses. |
265 |
|
|
266 |
|
Then, in a private protocol between wortel and physmem, the following |
267 |
|
happens: |
268 |
|
|
269 |
|
\begin{enumerate} |
270 |
|
\item Physmem requests all system memory from wortel. Wortel maps the |
271 |
|
memory from $\sigma_0$ and maps it to physmem. |
272 |
|
|
273 |
|
\begin{comment} |
274 |
|
The memory is mapped, not granted, to allow wortel (of which we |
275 |
|
think as a manager OS here) to unmap and recover the memory in |
276 |
|
case of a (possibly forced) system shutdown. |
277 |
|
\end{comment} |
278 |
|
|
279 |
|
\item For each module that has not been used yet, wortel requests a |
280 |
|
capability in physmem that can be used to map in pages from the |
281 |
|
range of memory that the module occupies. These capabilities should |
282 |
|
implement the same pager interface that mappable files implement. |
283 |
|
|
284 |
The rootserver copies (or moves) the physical memory server |
\begin{comment} |
|
executable image to the right location in memory, according to its |
|
|
respective ELF header. It also initializes the BSS section to zero. |
|
|
|
|
|
Then it follows the \texttt{exec()} protocol to startup the new |
|
|
task. This should be done as transparently as possible. All pages |
|
|
the rootserver provides because of page faults should be granted. |
|
|
The rootserver waits for the physical memory server to contact the |
|
|
rootserver thread. Then the following startup protocol is walked |
|
|
through: |
|
|
|
|
|
\begin{enumerate} |
|
|
\item The physical memory server requests all system memory from the |
|
|
rootserver. The rootserver maps the memory from $\sigma_0$ and |
|
|
grants it to the physical memory server. Alternatively, the |
|
|
physical memory server might get the memory directly from |
|
|
$\sigma_0$, but it should ask the rootserver for the amount and |
|
|
location of memory to get. |
|
|
|
|
|
\item For each module that has not been used yet, the rootserver |
|
|
requests a capability in the physical memory server that can be |
|
|
used to map in pages from the range of memory that the module |
|
|
occupies. These capabilities should implement the same pager |
|
|
interface that mappable files implement. |
|
|
|
|
285 |
The idea is that these capabilities can be used in the |
The idea is that these capabilities can be used in the |
286 |
\texttt{exec()} protocol to start up the tasks for these modules. |
\texttt{exec()} protocol to start up the tasks for these modules. |
287 |
If a module is not a task, the capability can be used to access |
If a module is not a task, the capability can be used to access |
288 |
the module data by mapping it into the address space like a file. |
the module data by mapping it into the address space like a file. |
289 |
The physical memory server can even swap out pages that back these |
Physmem can even swap out pages that back these objects on memory |
290 |
objects on memory pressure. |
pressure. |
291 |
|
|
292 |
So, the physical memory server is in fact a simple filesystem for |
So, the physical memory server is in fact a simple filesystem for |
293 |
these initial tasks, usable only for mapping operations. |
these initial tasks, usable only for mapping operations. |
|
|
|
|
\item The rootserver can then start up the other tasks in the module |
|
|
list using the normal \texttt{exec()} protocol. |
|
|
\end{enumerate} |
|
|
|
|
|
The result is that all tasks except for the rootserver can be |
|
|
started like normal Hurd tasks, and can also be swapped out. |
|
|
\end{comment} |
|
294 |
|
|
295 |
|
Wortel can then start up the other tasks in the module list |
296 |
|
using the normal \texttt{exec()} protocol. |
297 |
|
\end{comment} |
298 |
|
\end{enumerate} |
299 |
|
|
300 |
|
The result is that all tasks except for the rootserver can be started |
301 |
|
and manage their memory through physmem like normal Hurd tasks. |
302 |
|
|
303 |
|
Later on, wortel will provide physmem with further information |
304 |
|
retrieved from the task and deva servers. |
305 |
|
|
306 |
|
|
307 |
|
\section{The task server} |
308 |
|
|
309 |
|
The task server is the second Hurd server started by wortel. Its |
310 |
|
responsibility is to keep track of allocation of task and thread IDs |
311 |
|
in the system, and manage related resources (recording and restricting |
312 |
|
CPU usage). |
313 |
|
|
314 |
|
FIXME More has to be said here. |
315 |
|
|
316 |
|
|
317 |
|
\section{The device access server deva} |
318 |
|
|
319 |
|
The device access server deva is the third Hurd server started by |
320 |
|
wortel. It implements access to a low-level device driver framework |
321 |
|
in a way that transparently fits into the overall Hurd system. This |
322 |
|
means that access to device drivers is managed via capabilities, and |
323 |
|
that physmem containers are used for data exchange between a |
324 |
|
user-level application and a low-level device driver. |
325 |
|
|
326 |
|
It also provides system integration services to the underlying |
327 |
|
low-level device driver framework. In particular, it intermediates |
328 |
|
access to privileged resources and provides device drivers and related |
329 |
|
data from the systems filesystem. |
330 |
|
|
331 |
|
FIXME More has to be said here. |
332 |
|
|
333 |
|
|
334 |
|
\section{The device access server archive} |
335 |
|
|
336 |
|
The device access server needs to load device drivers before a root |
337 |
|
filesystem service is available. In particular, it needs to be able |
338 |
|
to provide device drivers for the root filesystem to the device driver |
339 |
|
framework. |
340 |
|
|
341 |
|
The device access server archive is an archive of device drivers that |
342 |
|
is loaded by the bootloader and contains drivers necessary to run the |
343 |
|
root filesystem. |
344 |
|
|
345 |
|
|
346 |
|
\section{The root filesystem} |
347 |
|
|
348 |
|
The root filesystem is the fourth and last Hurd server started by |
349 |
|
wortel. After the root filesystem starts up and has exchanged the |
350 |
|
necessary bootstrap information with deva, it starts up the rest of |
351 |
|
the operating system services from its filesystem. |
352 |
|
|
353 |
|
The root filesystem is the first program to actually run in a proper |
354 |
|
environment, given that it can access device drivers, task and physmem |
355 |
|
services. |
356 |
|
|
357 |
|
\begin{comment} |
358 |
|
From the time the root filesystem starts up, the bootstrap continues |
359 |
|
roughly as it is implemented in the Hurd running on GNU Mach. |
360 |
|
\end{comment} |