Device I/O, Interrupts, and Systems-on-Chip
Stub. The canonical device I/O model (memory-mapped or port-mapped registers, polling), interrupts as the alternative to polling and the full interrupt-handling path (vector, handler, context save/restore), how a system-on-chip composes a CPU with devices and interrupt controllers, and device abstraction layers such as VirtIO.
How software talks to hardware. Starts with the device model every driver assumes — a device exposes a small set of registers (status, control, data) the CPU reads and writes, either via memory-mapped I/O or dedicated port instructions — and the naive polling loop that checks a status register repeatedly. Interrupts replace polling with the device notifying the CPU asynchronously, which requires the full mechanism: an interrupt vector table, saving and restoring the interrupted context, and a handler that runs with interrupts often disabled to avoid re-entrancy bugs. A system-on-chip (SoC) is the concrete package all of this happens inside — CPU cores, memory controller, and an interrupt controller multiplexing many devices’ interrupt lines. VirtIO is covered as a modern device abstraction layer that lets an OS talk to many different (often virtualized) devices through one standard driver interface.
Outline (TODO — flesh out each)
- The device I/O model — registers, memory-mapped vs. port-mapped I/O
- Polling
- Interrupts — vector table, handlers, context save/restore
- Systems-on-chip (SoCs) — composing CPU, memory, and devices
- Device abstraction layers — VirtIO