Device Drivers

A device driver is a loadable kernel module that manages data transfers between a device and the OS. Loadable modules are loaded at boot time or by request and are unloaded by request. A device driver is a collection of C routines and data structures that can be accessed by other kernel modules. These routines must use standard interfaces called entry points. Through the use of entry points, the calling modules are shielded from the internal details of the driver. See Device Driver Entry Points in Writing Device Drivers for more information on entry points.

A device driver declares its general entry points in its dev_ops(9S) structure. A driver declares entry points for routines that are related to character or block data in its cb_ops(9S) structure. Some entry points and structures that are common to most drivers are shown in the following diagram.

Figure 1–1 Typical Device Driver Entry Points

The Oracle Solaris OS provides many driver entry points. Different types of devices require different entry points in the driver. The following diagram shows some of the available entry points, grouped by driver type. No single device driver would use all the entry points shown in the diagram.

Figure 1–2 Entry Points for Different Types of Drivers

In the Oracle Solaris OS, drivers can manage physical devices, such as disk drives, or software (pseudo) devices, such as bus nexus devices or ramdisk devices. In the case of hardware devices, the device driver communicates with the hardware controller that manages the device. The device driver shields the user application layer from the details of a specific device so that application level or system calls can be generic or device independent.

Drivers are accessed in the following situations:

• System initialization. The kernel calls device drivers during system initialization to determine which devices are available and to initialize those devices.

• System calls from user processes. The kernel calls a device driver to perform I/O operations on the device such as open(2), read(2), and ioctl(2).

• User-level requests. The kernel calls device drivers to service requests from commands such as prtconf(1M).

• Device interrupts. The kernel calls a device driver to handle interrupts generated by a device.

• Bus reset. The kernel calls a device driver to re-initialize the driver, the device, or both when the bus is reset. The bus is the path from the CPU to the device.

The following diagram illustrates how a device driver interacts with the rest of the system.

Figure 1–3 Typical Device Driver Interactions