Device Drivers (see Fig. 2)

Figure 2: Logical positioning of device drivers. In reality all communications between drivers and device controllers goes over the bus.

• Drivers (originally) compiled into the kernel
  • Device installers were technicians
  • Number and types of devices rarely changed
• Nowadays they are dynamically loaded when needed
  • Linux modules
  • Typical users (device installers) can't build kernels
  • Number and types vary greatly; Even while OS is running (e.g hot-plug USB devices)
• Drivers classified into similar catagories; Block devices and character (stream of data) device
• OS defines a standard (internal) interface to the different classes of devices
• Device drivers job
  • translate request through the device-independent standard interface (open, close, read, write) into appropriate sequence of commands (register manipulations) for the particular hardware
  • Initialise the hardware at boot time, and shut it down cleanly at shutdown
• After issue the command to the device, the device either
  • Completes immediately and the driver simply return to the caller
  • Or, device must process the request and the driver usually blocks waiting for an I/O complete interrupt.
• Drivers are reentrant as they can be called by another process while a process is already blocked in the driver
  • Reentrant: Code that can be executed by more than one thread (or CPU) at the same time
  • Manages concurrency using synch primitives