Hardware and Drivers

In addition to managing essential hardware resources such as the CPU and memory, the operating system is also responsible for managing hardware peripherals that may be added to the system. This includes devices such as the keyboard and mouse, a USB flash drive, and the graphics card. Although the operating system is responsible for managing these devices, it does so with the help of drivers, which can be thought of as plug-ins that run inside the operating system kernel and allow the system to interface to hardware devices.

The code to support a hardware device can be found in two places: on the device itself (known as firmware) and on the computer (known as the driver). The role of the driver is to act on behalf of the operating system in controlling the hardware device. Driver code is loaded into the operating system kernel and is granted the same privileges as the rest of the kernel, including the ability to directly access hardware.

The driver has the responsibility of initializing the hardware when the device is plugged into the computer (or when the computer boots) and of translating requests from the operating system into a sequence of hardware-specific operations that the device needs to perform to complete the operating system's request.

The type of requests that a driver will receive from the operating system depends on what function the driver performs. For certain drivers, the operating system provides a framework for driver developers. For example, a sound card requires an audio driver to be written. The audio driver receives requests from the operating system that are specific to the world of audio, such as a request to create a 48 kHz audio output stream, followed by requests to output a provided packet of audio.

Drivers may also be built on top of other drivers and may request services provided by other drivers. For example, the driver of a USB audio input device uses the services of a lower-level generic USB driver to access its hardware. This relieves the developer from having to become intimate with the USB protocol, and the developer is instead free to concentrate on the specifics of his own device. As in the previous example, the audio driver receives requests from the operating system that represent audio stream operations, and in responding to these, the driver creates requests of its own that are passed to a lower-level USB driver. This allows a separation in the responsibility of each driver: The audio driver needs to concern itself only with handling audio requests and configuring the audio device, and the USB driver needs to concern itself only with the USB protocol and performing data transfers over the USB bus. An example of the way in which drivers can be layered is illustrated in Figure 1-7.

Figure 1-7. The chain of control requests in an audio request from application to hardware

Not all hardware fits into a specific class that is understood by the operating system. A specialized device, such as a 3D printer, is unlikely to have support from the operating system. Instead, the hardware manufacturer needs to write a generic driver for their hardware. As a generic driver, the operating system does not recognize the device as a printer and issue printing requests to it, but instead the driver is controlled by specialized application software, which communicates with the printer driver directly. The operating system provides a special system call to allow a user application to request an operation from a driver, known as an “i/o control” request, often shortened to “ioctl.” An ioctl specifies the operation to be performed and provides the driver with parameters required by the operation, which may include a buffer to place the result of the operation. Although the ioctl request is implemented as a system call to the operating system, the request is passed directly to the driver.