Device drivers are kernel code modules that manage hardware devices, translating high-level I/O operations into device-specific commands and protocols. Hardware controllers execute these commands and signal completion via interrupts. Device drivers abstract hardware differences and provide a uniform interface to user programs, isolating applications from hardware details.
From your study of I/O systems, you know that the operating system must manage a diverse collection of hardware devices — disks, keyboards, network interfaces, GPUs, printers, and more. From your understanding of interrupts, you know that hardware signals the CPU when an operation completes. Device drivers and controllers are the two layers that connect these concepts, sitting between the application's abstract "read this file" request and the physical act of spinning a disk platter or receiving a network packet.
A device controller is a piece of hardware — a chip or circuit board — that directly manages a device. The disk controller, for example, handles the mechanics of positioning the read/write head, managing the disk's internal buffer, and transferring data to system memory. The CPU communicates with the controller through device registers: small memory-mapped or port-mapped locations where the CPU writes commands ("read sector 42") and reads status ("operation complete, data ready"). The controller operates asynchronously — after the CPU issues a command, the controller handles the physical device independently and raises an interrupt when finished, freeing the CPU to do other work in the meantime.
A device driver is the kernel software that knows how to talk to a specific controller. It understands the register layout, the command protocol, the timing requirements, and the error conditions of one particular piece of hardware. When a user program calls `read()` on a file, the request passes through the filesystem layer and eventually reaches the appropriate device driver, which translates the abstract request into the specific register writes that the controller expects. When the controller raises an interrupt, the driver's interrupt handler runs, checks the status registers, moves data to the appropriate kernel buffer, and wakes up any process that was waiting for the I/O to complete.
The architectural insight is that drivers provide a uniform interface to the rest of the kernel. The kernel defines a standard set of operations — open, close, read, write, ioctl — and every driver implements these operations for its specific device. A program that reads from a file, a serial port, or a network socket uses the same `read()` system call; only the driver code differs. This abstraction is why you can write a program that reads input without knowing or caring whether the input comes from a physical keyboard, a USB device, or a virtual terminal — the driver translates between the universal interface and the hardware-specific reality.
Because drivers run in kernel space with full hardware access, a buggy driver can crash the entire system — corrupting memory, hanging on a failed interrupt, or mismanaging DMA transfers. This is why device drivers are the single largest source of operating system bugs in practice, and why modern OS designs increasingly push driver code into user space or use formal verification for critical drivers. The driver model is a compelling case study in the tension between abstraction (hiding hardware complexity) and trust (running third-party code with maximum privilege).