/[hurd]/hurd-l4/doc/device-drivers.tex
ViewVC logotype

Diff of /hurd-l4/doc/device-drivers.tex

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

revision 1.4 by wagi, Mon Mar 22 00:26:50 2004 UTC revision 1.5 by marcus, Thu Oct 7 16:07:30 2004 UTC
# Line 64  must be pinned down. Line 64  must be pinned down.
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    
# Line 111  perform the following tasks: Line 111  perform the following tasks:
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
# Line 124  perform the following tasks: Line 124  perform the following tasks:
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
# Line 132  perform the following tasks: Line 132  perform the following tasks:
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    
# Line 320  For more details see http://os.inf.tu-dr Line 320  For more details see http://os.inf.tu-dr
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    
# Line 371  controller. Important for the software h Line 371  controller. Important for the software h
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    
# Line 410  physical page mapping. Line 410  physical page mapping.
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}
# Line 425  then the rest of the bootstrapping proce Line 425  then the rest of the bootstrapping proce
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.
# Line 459  the root bus driver. Line 459  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
# Line 483  from the ext2 process to the IDE Driver. Line 483  from the ext2 process to the IDE Driver.
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).
# Line 492  transfered. Line 492  transfered.
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.
# Line 519  managers.  The default plugin manger (dP Line 519  managers.  The default plugin manger (dP
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.
   

Legend:
Removed from v.1.4  
changed lines
  Added in v.1.5

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