Before persistence proper, we need the thing that stores it: the input/output device. A program with no input is boring; one with no output is pointless. So — how does the OS talk to hardware?
The Crux: How To Integrate I/O Into Systems
How should I/O be integrated into systems? What are the general mechanisms, and how can we make them efficient?36.1 System Architecture
Devices don’t all hang off one wire — they attach through a hierarchy of buses bus The interconnect wiring devices to the CPU and memory, arranged as a hierarchy for physics and cost: a fast, short memory bus (CPU↔memory), a general I/O bus (e.g. PCIe) for higher-performance devices like graphics and NVMe, and slower peripheral buses (SCSI, SATA, USB) for disks, keyboards, and mice. Faster buses must be shorter and cost more, so high-demand components sit nearer the CPU. defined in ch. 36 — open in glossary , fastest nearest the CPU:
Figure 36.1: the bus hierarchy. Fast, short, expensive buses sit near the CPU; slow, cheap buses hold many devices further out.
Why a hierarchy? Physics and cost. A faster bus must be shorter (so it can’t fit many plugs) and is expensive to engineer — so high-performance parts (graphics, NVMe) go near the CPU, while slow devices (disks, keyboard, mouse) share a cheap peripheral bus that can hold many of them.
36.2 A Canonical Device
Every device has two parts: a hardware interface it presents to the system, and its internal structure (implementation). Simple devices use a few chips; complex ones pack a micro-controller, memory, and sometimes hundreds of thousands of lines of firmware firmware Software embedded within a hardware device that implements the abstraction the device presents to the system — for example, a modern RAID controller may contain hundreds of thousands of lines of firmware. defined in ch. 36 — open in glossary (software inside the hardware — e.g. a RAID controller):
Figure 36.3: a canonical device — a register interface on top, hidden internals below.
36.3 The Canonical Protocol
The interface is three device registers device register A small hardware location a device exposes as its interface. The canonical three are a STATUS register (read the device's current state), a COMMAND register (tell it to perform a task), and a DATA register (pass data in or out). The OS controls the device by reading and writing these registers. defined in ch. 36 — open in glossary : STATUS (read the device’s state), COMMAND (tell it to do a task), and DATA (pass bytes in or out). The OS drives the device through a four-step protocol — step through it:
while (STATUS == BUSY) // 1. wait until ready (poll)
;
write data to DATA register // 2. hand over the data
write command to COMMAND // ...and the command (starts it)
while (STATUS == BUSY) // 3. wait until done (poll)
;This busy-wait is POLLING: the OS keeps reading the status register until the device is free. Simple — but it burns CPU doing nothing useful.
Two ideas fall out. Step 1 and step 3 are polling polling Repeatedly reading a device's status register in a loop to learn its state (e.g. spinning while STATUS == BUSY). Simple, but it wastes CPU cycles busy-waiting on a slow device instead of doing useful work — the motivation for interrupts. defined in ch. 36 — open in glossary — busy-looping on the status register, which wastes CPU on a slow device. And when the CPU moves the data in step 2 (word by word), that’s programmed I/O (PIO) programmed i/o PIO: data movement in which the main CPU is directly involved, copying data to or from a device one word at a time via the data register. Simple but CPU-costly for large transfers, which is why DMA is used to offload it. defined in ch. 36 — open in glossary — fine for a few bytes, costly for a 4KB block. Both inefficiencies set up the next section:
The Crux: How To Avoid The Costs Of Polling
How can the OS check device status without frequent polling, lowering the CPU overhead of managing a device?Check yourself: devices and the canonical protocol
1.Why are devices attached through a HIERARCHY of buses instead of one shared bus?
2.A canonical device exposes three registers. What is each for?
3.In the canonical protocol, what is 'polling'?
4.What is programmed I/O (PIO)?
5.In step 2 of the protocol, why does writing the COMMAND register matter?
6.What is the main inefficiency of the canonical protocol as written?