A user program calls read() on a network socket. Which of the following best describes what happens next?
AThe program directly accesses the network hardware through memory-mapped registers
BThe OS filesystem layer handles the request identically to a disk read
CThe request passes through the network driver, which translates it into hardware-specific register commands; the controller operates independently and raises an interrupt on completion
DThe controller runs the driver code to translate the high-level read into hardware commands
The uniform interface is the key: read() looks the same to the user program regardless of device type. The OS routes the call to the appropriate device driver (here, the network driver). The driver translates the abstract request into hardware-specific register writes that the network controller understands. The controller then operates asynchronously — independently managing the physical operation — and raises an interrupt when data is ready. Option D reverses the roles: the controller is hardware that executes commands; the driver is the software that issues them.
Question 2 Multiple Choice
Why are device driver bugs particularly dangerous compared to bugs in ordinary application code?
ADrivers run in user space with elevated permissions, allowing them to bypass file system checks
BDrivers run in kernel space with full hardware access, so a crash or memory corruption in a driver corrupts the entire OS
CDrivers interact directly with user data, making bugs a privacy risk rather than a stability risk
DDriver bugs are no more dangerous than application bugs — the OS isolates all processes equally
Device drivers execute in kernel space — the same privilege level as the OS core, with unrestricted access to all memory and hardware. A buggy driver can corrupt kernel data structures, hang waiting for an interrupt that never arrives, or mismanage DMA transfers that overwrite arbitrary memory. Any of these crashes the entire system, not just the process that opened the device. Application bugs, by contrast, are sandboxed by the OS: a crashing application is killed, not the kernel. This is why drivers are the largest source of OS bugs in practice.
Question 3 True / False
A device controller is a piece of hardware that manages a physical device; a device driver is the kernel software that communicates with that controller.
TTrue
FFalse
Answer: True
This is the fundamental two-layer architecture. The controller (hardware — a chip or circuit board) directly manages the physical device, operating asynchronously via commands written to its registers. The driver (kernel software) knows the specific register layout, command protocol, and error conditions for that controller. When a user program requests I/O, the driver issues the right register writes; when the operation completes, the controller raises an interrupt and the driver's interrupt handler processes the result.
Question 4 True / False
Device drivers provide a uniform interface so that most hardware device is accessed through the same kernel API, meaning most drivers implement identical logic internally.
TTrue
FFalse
Answer: False
Uniform interface means the *external* API is standardized (open, read, write, close, ioctl) — every driver exposes these same operations. But the *internal* implementation is completely device-specific: the disk driver writes one set of register commands; the keyboard driver writes entirely different ones. The uniformity is at the interface boundary, not inside the driver. This is the essence of abstraction: standardized interface, heterogeneous implementation. A program can call read() on any device without knowing anything about the underlying hardware.
Question 5 Short Answer
Explain why the abstraction provided by device drivers matters for the rest of the operating system and for user programs.
Think about your answer, then reveal below.
Model answer: Without drivers providing a uniform interface, every application would need to know the specific command protocol of every hardware device it might encounter. Drivers hide this heterogeneity: the OS defines standard operations (open, read, write) and every driver implements them for its hardware. Applications, filesystems, and the OS itself interact with a standardized interface and remain unchanged when hardware changes. This also allows hardware vendors to update their devices without modifying the OS or applications — only the driver changes.
The driver abstraction is a classic application of the 'hide the implementation, expose a stable interface' principle. It enables hardware and software to evolve independently. It is also why the same program that reads from a keyboard works on any keyboard — the driver translates the device-specific signals into standard key events. The cost of this abstraction is the privilege required: to access hardware directly, drivers must run in kernel space, which is why their bugs are so dangerous and why the industry has explored user-space driver architectures to limit blast radius.