/[hurd]/hurd-l4/doc/booting.tex
ViewVC logotype

Diff of /hurd-l4/doc/booting.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.2 by marcus, Thu Oct 7 16:07:30 2004 UTC revision 1.3 by marcus, Wed Oct 27 20:41:52 2004 UTC
# Line 27  root = (hd0,0) Line 27  root = (hd0,0)
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    
# Line 156  yet supported. Line 155  yet supported.
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
# Line 176  wrappers for the system calls to other u Line 177  wrappers for the system calls to other u
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}
# Line 218  initial task in a generalized manner. Line 236  initial task in a generalized manner.
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}

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26