Device Driver
A device driver is a piece of software, usually running as part of the operating system kernel, that knows how to operate one particular kind of hardware and presents it to the rest of the system through a standard, generic interface. A graphics card, a keyboard, a network adapter and a solid-state drive all speak different electrical and command languages; the driver is the translator that turns a general request such as "send this packet" or "read these blocks" into the exact register writes, queues and interrupts that specific chip understands, so that applications and even the rest of the kernel never need to know which manufacturer's hardware is underneath.
The driver exists to separate what a device does from how a particular vendor's chip does it. Operating systems define abstract device classes — block devices for storage, network interfaces, character devices for serial-like streams, displays, audio and input — and each driver implements the operations its class requires. This is why a program can call the same read function on a file whether it lives on a SATA disk, an NVMe drive or a USB stick, and why a new network card needs a new driver rather than a new web browser. In Unix-like systems devices even appear as entries such as /dev/sda, so ordinary file operations reach the driver without the application noticing.
Drivers usually run in kernel mode, which makes them powerful and dangerous at once. To handle interrupts and move data by direct memory access, a driver typically needs the same unrestricted privileges as the kernel core, so in monolithic designs like Linux and Windows a driver bug can corrupt memory or freeze the machine, and drivers have historically been the leading source of operating-system crashes. Several mitigations exist: Windows requires kernel-mode drivers on 64-bit versions to be digitally signed, which began with Windows Vista; Windows and macOS have moved many drivers to user mode; and microkernel systems run drivers as isolated processes from the outset. Even so, a faulty kernel-mode component can be catastrophic, as the widespread Windows outage of July 2024 caused by a faulty update to a security vendor's kernel-level sensor demonstrated.
Matching drivers to hardware is the part of computing that used to be painful and is now mostly invisible. In the early PC era, adding a card meant locating the right driver disk and setting jumpers or IRQ numbers by hand; Windows 95 popularized Plug and Play, where devices announce their identity and the system selects a driver automatically, and modern buses such as PCI Express and USB identify every device with vendor and product codes for exactly that purpose. Standard device classes mean that many peripherals need no vendor driver at all, because USB keyboards, mice and flash drives follow published class specifications that every major operating system implements. Linux went further by merging most drivers into the kernel source itself, which is why so much hardware works immediately after installation.
Drivers are central to GPU computing and machine learning, where version mismatches are a classic source of trouble. A GPU's driver exposes the device to user-space libraries such as CUDA from NVIDIA or ROCm from AMD, and each version of those libraries requires a minimum driver version; a framework that reports "no CUDA-capable device found" is very often facing an old, missing or mismatched driver rather than a broken card. Containers add a wrinkle: a container carries libraries but shares the host kernel, so the kernel-side driver must be installed on the host and exposed to the container. Related is the matter of firmware, which is code stored on the device itself; a driver runs on the host processor and controls the device, while firmware runs on the device, and some drivers upload firmware blobs to the hardware at start-up.
Drivers are also an attack surface and a compatibility burden. Because they run with kernel privileges, vulnerable signed drivers can be abused by malware in what are called bring-your-own-vulnerable-driver attacks, and operating systems maintain blocklists against known offenders. Compatibility problems arise when a vendor stops updating a driver for old hardware, leaving a perfectly working printer or scanner unsupported by a new operating-system release. The usual advice that newer drivers are always better is also only partly true: a new graphics driver commonly improves performance and fixes bugs, but occasionally introduces regressions, which is why many administrators pin driver versions on production machines and test updates first.
Read a device driver as an interpreter standing between two languages: the operating system speaks in general verbs such as read, write and send, the hardware speaks in vendor-specific registers and interrupts, and the driver, trusted with kernel privileges to bridge them, is why software can be written once for a class of devices and still work on thousands of different products.