Operating System Concepts Chapter 12 — I/O Systems Explained

// the one-minute version

Every device — keyboard, disk, network card — is reached through a controller the CPU talks to via registers. The CPU learns a device is ready either by polling (asking repeatedly, wasteful) or interrupts (being notified, efficient). For big transfers, DMA lets the device move data to memory directly, freeing the CPU. Above all that, a uniform driver layer hides each device's quirks, and the kernel adds buffering, caching, and spooling.

A CPU really only knows how to do math and move bytes. It has no idea what a keyboard or SSD is. The I/O system is the set of layers that lets that math-machine drive thousands of wildly different devices through one clean interface.

01 Device controllers and how the CPU talks to them

The CPU never wires directly to a device. Each device has a controller with registers the CPU reads and writes — a status register, a control register, and data registers. Writing control starts an operation; reading status checks if it's done. The CPU reaches these registers either through special I/O instructions or, more commonly, through memory-mapped I/O, where the registers appear at ordinary memory addresses and the CPU just reads/writes them like RAM.

02 Polling vs interrupts

How does the CPU know the device finished? Chapter 1's lesson returns:

Polling

The CPU repeatedly reads the status register: "done yet? done yet?" Simple, but it burns CPU cycles doing nothing while waiting.

Interrupts

The device raises an interrupt when ready; the CPU does other work meanwhile and responds only when notified. Far more efficient for anything slow.

key ideaPolling vs interrupts is the same trade-off you met with the timer in Chapter 1. For fast, predictable devices a quick poll can win; for slow or unpredictable ones (disk, network, keyboard), interrupts let the CPU stay productive. Real systems mix both, sometimes switching dynamically under load.

03 DMA: get the CPU out of the data path

Even with interrupts, having the CPU copy a megabyte one word at a time from a controller is a waste. Direct memory access (DMA) hands that job to a dedicated controller: the CPU says "move this block to that memory address" and goes off to do other work. The DMA controller performs the transfer and raises a single interrupt when the whole block is done.

think of it likeWithout DMA the CPU is a manager personally carrying every box from the truck to the warehouse. With DMA it hires a mover (the DMA controller), says "put all these boxes in aisle 5," and gets back to managing — interrupted just once, when the job's complete.

04 The I/O software stack

I/O is built in layers, each hiding detail from the one above:

Interrupt handlers

Lowest level — respond to the raw hardware interrupt and hand off to the driver.

Device drivers

Per-device code that knows one device's exact registers and quirks, exposing a standard interface upward. Where device-specific complexity lives.

Kernel I/O subsystem

Device-independent services: naming, protection, buffering, caching, scheduling — shared by all devices.

Application I/O interface

The clean calls programs use (open/read/write), unaware which device is underneath.

noteDrivers are the genius of the design. Because every driver exposes the same interface upward, the kernel can treat a brand-new device it's never seen like any other — just load its driver. That's why you can plug in a new printer without rebuilding the OS. Drivers are also, notoriously, where most kernel bugs and crashes originate, since they're hardware-specific and numerous.

05 Kernel I/O services

The kernel adds three classic services on top of raw devices:

Buffering

Hold data in memory between producer and device to smooth speed mismatches and allow convenient transfer sizes.

Caching

Keep copies of recently used data (like disk blocks) in RAM so repeat accesses skip the slow device entirely.

Spooling

Queue output for a device that can't interleave streams — the classic example is a print spool holding jobs in line.

watch outBuffering and caching sound similar but aren't. A buffer holds the only copy of data in transit (speed-matching). A cache holds a spare copy of data that also lives elsewhere (speed-up). Cache copies can go stale and need invalidation; buffer contents are the real thing in flight.

06 Blocking, non-blocking, and asynchronous I/O

An I/O call can block — the process sleeps until the operation finishes (simple to reason about) — or be non-blocking — it returns immediately with whatever's available — or asynchronous — it returns instantly and the program is notified later when the data is ready. Servers handling thousands of connections lean on non-blocking/async I/O so one thread can juggle many streams without sleeping on each.

common catches & gotchas

Polling isn't always wrong — For ultra-fast devices the interrupt overhead can exceed a quick poll. "Interrupts always win" is an oversimplification.
Buffer ≠ cache — A buffer is data in flight (the only copy); a cache is a spare copy for speed. Mixing them up muddles every I/O discussion.
DMA still interrupts — once — DMA frees the CPU from copying, but the device still raises one interrupt at completion. It reduces interrupts, it doesn't eliminate them.
Drivers cause most crashes — Buggy, hardware-specific driver code is the leading source of kernel instability — a real-world reason microkernels push drivers to user space.
Memory-mapped I/O looks like RAM — Device registers can appear at memory addresses; a stray pointer write there can poke hardware. It's not ordinary memory.

07 Questions students actually ask

Why are interrupts usually better than polling?

Polling makes the CPU waste cycles repeatedly checking a status register. Interrupts let the CPU do useful work and respond only when the device signals it's ready — far better for slow or unpredictable devices.

What does DMA actually save?

It frees the CPU from copying large data blocks word by word. The DMA controller moves the whole block between device and memory independently, interrupting the CPU just once at the end.

Why is the driver layer so important?

Each driver hides one device's specific registers and quirks behind a standard interface, so the rest of the OS treats every device uniformly and supports new hardware just by loading a driver.

Buffer vs cache — what's the difference?

A buffer holds data in transit to smooth speed mismatches (the data itself, in flight). A cache holds a spare copy of data that also exists elsewhere, to speed repeat access (and can go stale).

What's the difference between non-blocking and asynchronous I/O?

Non-blocking returns immediately with whatever data is available right now. Asynchronous returns immediately and notifies you later when the full operation completes. Both let a program avoid sleeping on slow I/O.

08 Key takeaways

Devices are reached through controllers with status/control/data registers, often via memory-mapped I/O.
Polling wastes CPU; interrupts notify it only when needed.
DMA moves big blocks without the CPU, interrupting once at the end.
I/O is layered: interrupt handlers → drivers → kernel subsystem → app interface.
Drivers hide device quirks behind a uniform interface — and cause most kernel crashes.
The kernel adds buffering, caching, and spooling; I/O can be blocking, non-blocking, or async.

09 Wrapping up

The I/O system lets the OS drive any device uniformly. The most important thing it drives is storage — and on top of storage the OS builds the abstraction users care about most: files. Next up: File-System Interface.

Operating System Concepts Chapter 12 — I/O Systems.