64 |
|
|
65 |
If an application wants to send or receive data to/from a device |
If an application wants to send or receive data to/from a device |
66 |
driver it has to tell the virtual driver the page on which the |
driver it has to tell the virtual driver the page on which the |
67 |
operation has to be executed. Since the application doesn't know |
operation has to be executed. Since the application doesn't know the |
68 |
the virtual-real memory mapping, it has to ask the physical memory |
virtual-real memory mapping, it has to ask the physical memory manager |
69 |
manager for the real memory address of the page in question. If the |
for the real memory address of the page in question. If the page is |
70 |
page is not directly mapped from the physical memory manager the |
not directly mapped from the physical memory manager the application |
71 |
application ask the mapper (another application which has mapped |
asks the mapper (another application which has mapped this memory |
72 |
this memory region the first application) to resolve the mapping. |
region to the first application) to resolve the mapping. This can be |
73 |
This can be done recursively. Normally, this resolving of mapping |
done recursively. Normally, this resolving of a mapping can be sped |
74 |
can be speed up using a cache services, since a small number of |
up using a cache services, since a small number of pages are reused |
75 |
pages are reused very often. |
very often. |
76 |
|
|
77 |
With the scheme, the drivers do not have to take special care of |
With the scheme, the drivers do not have to take special care of zero |
78 |
zero copying if there is only one virtual driver. When there is |
copying if there is only one virtual driver. When there is more than |
79 |
more than one virtual driver pages have to copied for all other |
one virtual driver pages have to be copied for all other virtual |
80 |
virtual drivers. |
drivers. |
81 |
|
|
82 |
\subsection{Physical versus logical device view} |
\subsection{Physical versus logical device view} |
83 |
|
|
111 |
file\footnote{It might be a good idea, if the device driver has no |
file\footnote{It might be a good idea, if the device driver has no |
112 |
notion how the configuraiton is stored. It just asks the bus driver |
notion how the configuraiton is stored. It just asks the bus driver |
113 |
which should know how to get the configuration.} or if the driver is |
which should know how to get the configuration.} or if the driver is |
114 |
a needed for bootstrapping configuration can be given as argument on |
needed for bootstrapping configuration can be given as argument on |
115 |
its stack. In some cases the bus doesn't generate insertion/removal |
its stack. In some cases the bus doesn't generate insertion/removal |
116 |
events, but can still support some form of hotplug functionality if |
events, but can still support some form of hotplug functionality if |
117 |
the user tells the driver when a change to the bus configuration has |
the user tells the driver when a change to the bus configuration has |
124 |
info, so it can access the device it needs. This configuration data |
info, so it can access the device it needs. This configuration data |
125 |
typically consists of the bus addresses of the device and possibly |
typically consists of the bus addresses of the device and possibly |
126 |
IRQ numbers or DMA channel ID's. The device driver is loaded by the |
IRQ numbers or DMA channel ID's. The device driver is loaded by the |
127 |
assotiatet plugin manager. |
associated plugin manager. |
128 |
\item Provide access to devices |
\item Provide access to devices |
129 |
|
|
130 |
This means the bus driver should be able to perform a bus |
This means the bus driver should be able to perform a bus |
132 |
involves sending a message and waiting for reply (eg. SCSI, USB, |
involves sending a message and waiting for reply (eg. SCSI, USB, |
133 |
IEEE 1394, Fibre Channel,...). The driver should provide |
IEEE 1394, Fibre Channel,...). The driver should provide |
134 |
send/receive message primitives in this case. In other cases |
send/receive message primitives in this case. In other cases |
135 |
devices on the bus can be accessed by doing a memory accesses or by |
devices on the bus can be accessed by memory accesses or by using |
136 |
using special I/O instructions. In this case the driver should |
special I/O instructions. In this case the driver should provide |
137 |
provide mapping and unmapping primitives so a client device driver |
mapping and unmapping primitives so a client device driver can get |
138 |
can get access to the memory range or is allowed to access the I/O |
access to the memory range or is allowed to access the I/O |
139 |
addresses. The client device driver should use a library, which is |
addresses. The client device driver should use a library, which is |
140 |
bus dependant, to access the device on the bus. This library hides |
bus dependant, to access the device on the bus. This library hides |
141 |
the platform specific details of accessing the bus. |
the platform specific details of accessing the bus. |
142 |
\item Rescans |
\item Rescans |
143 |
|
|
144 |
Furthermore the bus driver must also support rescans for hardware. |
Furthermore the bus driver must also support rescans for hardware. |
145 |
It might be that not all drivers are found during bootstrapping and |
It might be that not all drivers are found during bootstrapping and |
146 |
hence later on drivers could be loaded. This is done by regenerate |
hence later on drivers could be loaded. This is done by generating |
147 |
new attach notification sending to bus's plugin manager. The plugin |
new attach notification, which are sent to the bus's plugin manager. |
148 |
manager loads then if possible a new driver. A probe funtion is not |
The plugin manager then loads a new driver, if possible. A probe |
149 |
needed since all supported hardware can be identified by |
funtion is not needed since all supported hardware can be identified |
150 |
vendor/device identifactions (unlike ISA hardware). For hardware |
by vendor/device identification (unlike ISA hardware). For hardware |
151 |
busses which don't support such identifaction only static |
busses which don't support such identification only static |
152 |
configuration is possible (configuration scripts etc.) |
configuration is possible (configuration scripts etc.) |
153 |
\end{itemize} |
\end{itemize} |
154 |
|
|
320 |
Operations: |
Operations: |
321 |
\begin{itemize} |
\begin{itemize} |
322 |
\item attach\_irq : attach an ISR thread to the IRQ |
\item attach\_irq : attach an ISR thread to the IRQ |
323 |
\item detach\_irq : detach an ISR thread form the IRQ |
\item detach\_irq : detach an ISR thread from the IRQ |
324 |
\end{itemize} |
\end{itemize} |
325 |
|
|
326 |
|
|
371 |
acknowledge IRQ's at each controller. So to acknowledge an IRQ from |
acknowledge IRQ's at each controller. So to acknowledge an IRQ from |
372 |
the second 8259 connected to the first 8259 connected to another |
the second 8259 connected to the first 8259 connected to another |
373 |
interrupt controller, you have to give an ACK command to each of those |
interrupt controller, you have to give an ACK command to each of those |
374 |
controllers. Another import fact is that on PC architecture the order |
controllers. Another import fact is that on the PC architecture the |
375 |
of the ACKs is important. |
order of the ACKs is important. |
376 |
|
|
377 |
\subsubsection{Shared IRQs} |
\subsubsection{Shared IRQs} |
378 |
|
|
410 |
\section{Bootstrapping} |
\section{Bootstrapping} |
411 |
|
|
412 |
The device driver framework will be started by deva, which is started |
The device driver framework will be started by deva, which is started |
413 |
by wortel. All drivers and server (e.g. the plugin manager) are |
by wortel. All drivers and servers (e.g. the plugin manager) are |
414 |
stored in a archive which will be extracted by deva. |
stored in a archive which will be extracted by deva. |
415 |
|
|
416 |
\subsection{deva} |
\subsection{deva} |
425 |
|
|
426 |
\subsection{Plugin Manager} |
\subsection{Plugin Manager} |
427 |
|
|
428 |
A Plugin manager handles driver loading for devices. It ask for drivers |
A Plugin manager handles driver loading for devices. It asks deva for |
429 |
deva. |
drivers. |
430 |
|
|
431 |
The first plugin server does also some bootstrapping. First, it starts |
The first plugin server does also some bootstrapping. First, it starts |
432 |
the root bus driver. |
the root bus driver. |
459 |
\label{fig:ddf_insert_event} |
\label{fig:ddf_insert_event} |
460 |
\end{figure} |
\end{figure} |
461 |
|
|
462 |
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 |
463 |
the new hardware device as follows (see Figure~\ref{fig:ddf_insert_event}): |
the new hardware device as follows (see Figure~\ref{fig:ddf_insert_event}): |
464 |
|
|
465 |
\begin{enumerate} |
\begin{enumerate} |
466 |
\item The PCI Bus Driver detects a hardware device for which now driver |
\item The PCI Bus Driver detects a hardware device for which no driver |
467 |
has been loaded yet. It generates an insert event which is sends to |
has been loaded yet. It generates an insert event which it sends to |
468 |
one (all?) registered entity. The interface for the event handler has |
one (all?) registered entity. The interface for the event handler has |
469 |
not been decided yet. |
not been decided yet. |
470 |
\item The Root Bus Driver receives the event signal. Note it is not |
\item The Root Bus Driver receives the event signal. Note it is not |
471 |
necessary that the Root Bus Driver handles for all drivers the insert |
necessary that the Root Bus Driver handles the insert signal for all |
472 |
signal. It forwards the signal to the/a Plugin Manager (PLM). |
drivers. It forwards the signal to the/a Plugin Manager (PLM). |
473 |
\item The/a Plugin Manager (PLM) asks Deva to load the driver binary |
\item The/a Plugin Manager (PLM) asks Deva to load the driver binary |
474 |
for the new device. |
for the new device. |
475 |
\item Deva forwards the loading request to the ext2 filesystem |
\item Deva forwards the loading request to the ext2 filesystem |
483 |
the IDE Driver reads the device driver from the disk. |
the IDE Driver reads the device driver from the disk. |
484 |
\item The IDE Driver returns the data. |
\item The IDE Driver returns the data. |
485 |
\item ddwrapper returns the data. XXX This might be wrong. IFRC, the |
\item ddwrapper returns the data. XXX This might be wrong. IFRC, the |
486 |
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 |
487 |
transfered. |
transfered. |
488 |
\item Ext2 returns the device driver (data). |
\item Ext2 returns the device driver (data). |
489 |
\item Deva returns the device driver (data). |
\item Deva returns the device driver (data). |
492 |
\item wortel returns ``a new address space''. |
\item wortel returns ``a new address space''. |
493 |
\item Deva returns ``a new address space''. |
\item Deva returns ``a new address space''. |
494 |
\item PLM is registered as pagefault handler for the new driver |
\item PLM is registered as pagefault handler for the new driver |
495 |
address space. The bootstrap thread starts to run an generated a |
address space. The bootstrap thread starts to run and generates a |
496 |
page fault. |
page fault. |
497 |
\item PLM asks Deva for memory. |
\item PLM asks Deva for memory. |
498 |
\item Deva asks physmem for memory. |
\item Deva asks physmem for memory. |
519 |
a new plugin manager. It is loaded like a normal driver. The default |
a new plugin manager. It is loaded like a normal driver. The default |
520 |
plugin manager will also act as pager for the new plugin manager. |
plugin manager will also act as pager for the new plugin manager. |
521 |
When the new plugin manager is activated it registers itself to the |
When the new plugin manager is activated it registers itself to the |
522 |
Deva as new plugin manager. Deva will send all signal/messages from |
Deva as new plugin manager. Deva will send all signals/messages from |
523 |
outside of the ddf to all registered plugin managers. |
outside of the ddf to all registered plugin managers. |
|
|
|