Other meanings of Device driver
Computing
A device driver is software that enables an operating system to communicate with hardware devices. It translates operating-system requests into device-specific operations and returns results in a form that applications and system services can use.
A device driver provides the operating system with a controlled interface to a particular class or model of hardware. Applications normally address a file, socket, graphics API, or other operating-system service rather than programming a device’s registers directly; the driver performs that translation. A printer driver, for example, converts print jobs into commands and data understood by a printer, while a storage driver presents device blocks through the operating system’s storage stack.
Drivers commonly manage initialization, configuration, data transfer, error reporting, and shutdown. They may support physical hardware such as a PCI controller or USB peripheral, or virtual hardware supplied by a hypervisor. The abstraction is not complete: capabilities, timing, power states, and failure behavior can remain device-specific. Operating systems therefore organize drivers into frameworks that standardize common functions while leaving hardware-specific work to the driver.
Driver operation is organized around an operating-system I/O framework and a device-specific implementation. In the Linux kernel, the driver model connects devices, buses, and drivers and helps manage discovery, binding, power management, and removal.1 Windows similarly supplies driver frameworks, device stacks, plug-and-play mechanisms, and standardized request objects through its Windows Driver Kit.2
A request can travel through several layers: an application-facing subsystem, a class driver, a bus driver, and finally a vendor or hardware-specific driver. The device may signal completion with an interrupt, while DMA transfers data between the device and memory without requiring the processor to copy every byte. Drivers must coordinate concurrency, map device memory safely, and handle cancellation and timeouts. These responsibilities make a driver more than a simple library of hardware commands.
Because many drivers run with high privilege, a defect can affect the entire operating system rather than only one application. Incorrect memory access, race conditions, unchecked device input, or a failed power transition can cause data loss, crashes, or security vulnerabilities. DMA-capable devices also require carefully managed memory mappings and synchronization; operating systems provide DMA APIs to account for hardware and platform constraints.3
Modern platforms reduce these risks through driver signing, hardware-based isolation, restricted interfaces, and frameworks that move selected drivers into user space. Windows requires appropriate signing for many kernel-mode drivers, while Apple’s DriverKit model is designed for supported hardware drivers to operate outside the kernel.43 Updates must preserve compatibility with the operating system and firmware, and a driver can be disabled or rolled back when installation causes instability. Security review therefore includes the driver’s update path, not only its source code.
Drivers also exist for hardware that users rarely recognize as a separate device. A virtual network adapter, a software-defined disk, a sensor hub, a cryptographic accelerator, and a hypervisor’s paravirtual device can all require drivers. Some drivers expose no ordinary user-facing interface at all: they coordinate power, thermal monitoring, hot-plug events, or communication between processors and embedded controllers.
Driver boundaries vary by operating system and device class. A graphics stack may divide work among a kernel driver, a user-space driver, a display server, and a graphics API; a USB device may be handled partly by generic class and bus drivers rather than a vendor-specific module. Driver support can also outlive the original hardware through emulation or compatibility layers. Conversely, a device may function poorly with a generic driver because advanced features, calibrated timing, or firmware-specific behavior is unavailable. These edge cases explain why “supported by the operating system” does not always mean “fully supported.”
The term refers here exclusively to software that enables an operating system to communicate with hardware devices; it does not refer to human operators, device ownership, or unrelated meanings of “driver.”
Help improve the encyclopedia. Reports go straight to the site manager.