Index: doc/booting.tex =================================================================== RCS file: /cvsroot/hurd/hurd-l4/doc/booting.tex,v retrieving revision 1.1 diff -u -p -r1.1 booting.tex --- doc/booting.tex 7 Sep 2003 21:49:30 -0000 1.1 +++ doc/booting.tex 31 May 2004 23:21:20 -0000 @@ -134,7 +134,7 @@ rootserver. page faults. \end{comment} -The thread ID of $\sigma_0$ is (\verb/UserBase, 1)/. +The thread ID of $\sigma_0$ is (\verb/UserBase, 1/). \begin{comment} We will write all thread IDs in the form (\verb/thread nr/, @@ -153,7 +153,7 @@ $\sigma_1$ is intended to provide a pagi This will allow orthogonal persistence to be implemented. It is not yet supported. -The thread ID of $\sigma_1$ is (\verb/UserBase + 1, 1)/. +The thread ID of $\sigma_1$ is (\verb/UserBase + 1, 1/). \section{The rootserver} @@ -179,7 +179,7 @@ wrappers for the system calls to other u The rootserver has the following initial state: \begin{itemize} -\item Its thread ID is (\verb/UserBase + 2/, 1). +\item Its thread ID is (\verb/UserBase + 2, 1/). \item The priority is set to the 255, the maximum value. @@ -193,7 +193,7 @@ all other registers are undefined (inclu \item The pager is set to $\sigma_0$. -\item The exception handler set to \verb/nilthread/. +\item The exception handler is set to \verb/nilthread/. \item The scheduler is set to the rootserver thread itself. \end{itemize} Index: doc/device-drivers.tex =================================================================== RCS file: /cvsroot/hurd/hurd-l4/doc/device-drivers.tex,v retrieving revision 1.4 diff -u -p -r1.4 device-drivers.tex --- doc/device-drivers.tex 22 Mar 2004 00:26:50 -0000 1.4 +++ doc/device-drivers.tex 31 May 2004 23:21:21 -0000 @@ -68,15 +68,15 @@ operation has to be executed. Since the the virtual-real memory mapping, it has to ask the physical memory manager for the real memory address of the page in question. If the page is not directly mapped from the physical memory manager the -application ask the mapper (another application which has mapped -this memory region the first application) to resolve the mapping. -This can be done recursively. Normally, this resolving of mapping -can be speed up using a cache services, since a small number of +application asks the mapper (another application which has mapped +this memory region to the first application) to resolve the mapping. +This can be done recursively. Normally, this resolving of a mapping +can be sped up using a cache service, since a small number of pages are reused very often. With the scheme, the drivers do not have to take special care of zero copying if there is only one virtual driver. When there is -more than one virtual driver pages have to copied for all other +more than one virtual driver pages have to be copied for all other virtual drivers. \subsection{Physical versus logical device view} @@ -111,7 +111,7 @@ perform the following tasks: file\footnote{It might be a good idea, if the device driver has no notion how the configuraiton is stored. It just asks the bus driver which should know how to get the configuration.} or if the driver is - a needed for bootstrapping configuration can be given as argument on + needed for bootstrapping, the configuration can be given as arguments on its stack. In some cases the bus doesn't generate insertion/removal events, but can still support some form of hotplug functionality if the user tells the driver when a change to the bus configuration has @@ -124,7 +124,7 @@ perform the following tasks: info, so it can access the device it needs. This configuration data typically consists of the bus addresses of the device and possibly IRQ numbers or DMA channel ID's. The device driver is loaded by the - assotiatet plugin manager. + associated plugin manager. \item Provide access to devices This means the bus driver should be able to perform a bus @@ -132,23 +132,24 @@ perform the following tasks: involves sending a message and waiting for reply (eg. SCSI, USB, IEEE 1394, Fibre Channel,...). The driver should provide send/receive message primitives in this case. In other cases - devices on the bus can be accessed by doing a memory accesses or by + devices on the bus can be accessed by memory access or by using special I/O instructions. In this case the driver should provide mapping and unmapping primitives so a client device driver can get access to the memory range or is allowed to access the I/O addresses. The client device driver should use a library, which is bus dependant, to access the device on the bus. This library hides - the platform specific details of accessing the bus. + the platform specific details of accessing the bus. \item Rescans Furthermore the bus driver must also support rescans for hardware. It might be that not all drivers are found during bootstrapping and - hence later on drivers could be loaded. This is done by regenerate - new attach notification sending to bus's plugin manager. The plugin - manager loads then if possible a new driver. A probe funtion is not + hence later on drivers could be loaded. This is done by generating + new attach notifications, which are sent to the bus's plugin manager. + The plugin manager then loads a new driver, if possible. + A probe funtion is not needed since all supported hardware can be identified by - vendor/device identifactions (unlike ISA hardware). For hardware - busses which don't support such identifaction only static + vendor/device identification (unlike ISA hardware). For hardware + busses which don't support such identification only static configuration is possible (configuration scripts etc.) \end{itemize} @@ -320,7 +321,7 @@ For more details see http://os.inf.tu-dr Operations: \begin{itemize} \item attach\_irq : attach an ISR thread to the IRQ -\item detach\_irq : detach an ISR thread form the IRQ +\item detach\_irq : detach an ISR thread from the IRQ \end{itemize} @@ -371,7 +372,7 @@ controller. Important for the software h acknowledge IRQ's at each controller. So to acknowledge an IRQ from the second 8259 connected to the first 8259 connected to another interrupt controller, you have to give an ACK command to each of those -controllers. Another import fact is that on PC architecture the order +controllers. Another import fact is that on the PC architecture the order of the ACKs is important. \subsubsection{Shared IRQs} @@ -410,7 +411,7 @@ physical page mapping. \section{Bootstrapping} The device driver framework will be started by deva, which is started -by wortel. All drivers and server (e.g. the plugin manager) are +by wortel. All drivers and the server (e.g. the plugin manager) are stored in a archive which will be extracted by deva. \subsection{deva} @@ -425,8 +426,8 @@ then the rest of the bootstrapping proce \subsection{Plugin Manager} -A Plugin manager handles driver loading for devices. It ask for drivers -deva. +A Plugin manager handles driver loading for devices. It asks deva for +drivers. The first plugin server does also some bootstrapping. First, it starts the root bus driver. @@ -459,17 +460,17 @@ the root bus driver. \label{fig:ddf_insert_event} \end{figure} -If a simple hardware device is found the ddf will load an driver for +If a simple hardware device is found the ddf will load a driver for the new hardware device as follows (see Figure~\ref{fig:ddf_insert_event}): \begin{enumerate} -\item The PCI Bus Driver detects a hardware device for which now driver -has been loaded yet. It generates an insert event which is sends to +\item The PCI Bus Driver detects a hardware device for which no driver +has been loaded yet. It generates an insert event which it sends to one (all?) registered entity. The interface for the event handler has not been decided yet. \item The Root Bus Driver receives the event signal. Note it is not -necessary that the Root Bus Driver handles for all drivers the insert -signal. It forwards the signal to the/a Plugin Manager (PLM). +necessary that the Root Bus Driver handles the insert signal for all drivers. +It forwards the signal to the/a Plugin Manager (PLM). \item The/a Plugin Manager (PLM) asks Deva to load the driver binary for the new device. \item Deva forwards the loading request to the ext2 filesystem @@ -483,7 +484,7 @@ from the ext2 process to the IDE Driver. the IDE Driver reads the device driver from the disk. \item The IDE Driver returns the data. \item ddwrapper returns the data. XXX This might be wrong. IFRC, the -data is return in a container and only the handle of the container is +data is returned in a container and only the handle of the container is transfered. \item Ext2 returns the device driver (data). \item Deva returns the device driver (data). @@ -492,7 +493,7 @@ transfered. \item wortel returns ``a new address space''. \item Deva returns ``a new address space''. \item PLM is registered as pagefault handler for the new driver -address space. The bootstrap thread starts to run an generated a +address space. The bootstrap thread starts to run and generates a page fault. \item PLM asks Deva for memory. \item Deva asks physmem for memory. @@ -519,6 +520,6 @@ managers. The default plugin manger (dP a new plugin manager. It is loaded like a normal driver. The default plugin manager will also act as pager for the new plugin manager. When the new plugin manager is activated it registers itself to the -Deva as new plugin manager. Deva will send all signal/messages from +Deva as new plugin manager. Deva will send all signals/messages from outside of the ddf to all registered plugin managers. Index: libhurd-cap-server/README =================================================================== RCS file: /cvsroot/hurd/hurd-l4/libhurd-cap-server/README,v retrieving revision 1.5 diff -u -p -r1.5 README --- libhurd-cap-server/README 8 Apr 2004 00:40:38 -0000 1.5 +++ libhurd-cap-server/README 31 May 2004 23:21:21 -0000 @@ -20,7 +20,7 @@ An introduction to the capability system A server provides services to its clients. In a capability system the right to access a given service is called a capability. This right is -hold by a client. It was previously granted to the client by the +held by a client. It was previously granted to the client by the server. The client can then make use of this right, cease it, or transfer (copy) it to a new client. @@ -123,7 +123,7 @@ Capability Classes ------------------ Capability classes require a capability object definition (via storage -size and constructor/desctructor callbacks), and a demuxer for +size and constructor/destructor callbacks), and a demuxer for incoming RPC messages on capability objects from this class. After creating a class, you will usually want to start a manager Index: wortel/ia32-cmain.c =================================================================== RCS file: /cvsroot/hurd/hurd-l4/wortel/ia32-cmain.c,v retrieving revision 1.11 diff -u -p -r1.11 ia32-cmain.c --- wortel/ia32-cmain.c 26 Apr 2004 21:15:21 -0000 1.11 +++ wortel/ia32-cmain.c 31 May 2004 23:21:22 -0000 @@ -176,7 +176,7 @@ find_components (void) /* Add the argument string of the first module to the list of unused pages. */ add_unused_area ((l4_word_t) mod[0].string, - strlen ((char *) mod[0].string)); + strlen ((char *) mod[0].string) + 1); mods_count = mbi->mods_count - 1; if (mods_count > MOD_NUMBER) Index: wortel/wortel.c =================================================================== RCS file: /cvsroot/hurd/hurd-l4/wortel/wortel.c,v retrieving revision 1.29 diff -u -p -r1.29 wortel.c --- wortel/wortel.c 26 Apr 2004 21:15:21 -0000 1.29 +++ wortel/wortel.c 31 May 2004 23:21:32 -0000 @@ -223,7 +223,7 @@ setup_components (void) (because it is not a valid version ID), and we reserve 1 for wortel itself (incidentially, our thread version is already 1). Because we associate all non-task modules with the preceding - task, we bump up the task_id number up whenever a new task is + task, we bump up the task_id number whenever a new task is encountered. So start with one less than 2 to compensate that the first time around. */ hurd_task_id_t task_id = 2 - 1; @@ -331,8 +331,8 @@ start_physmem (void) ret = l4_thread_start (physmem, 0, mods[MOD_PHYSMEM].ip); if (!ret) - panic ("Sending startup message to physmem thread failed: %u", - l4_error_code ()); + panic ("Sending startup message to physmem thread failed: %s", + l4_strerror (l4_error_code ())); /* Set up the extra threads for physmem. FIXME: UTCB location has the same issues as described above. */ @@ -1096,7 +1096,7 @@ serve_requests (void) continue; } else if (label == WORTEL_MSG_SHUTDOWN) - panic ("Bootstrap failed"); + shutdown (); else panic ("Invalid message with tag 0x%x", msg_tag); }