Hardware Support, System Calls and OS Architecture

Interrupts: how the world gets the CPU's attention

An interrupt is a signal that makes the CPU stop what it is doing, save its state, and run a special routine — an interrupt handler (interrupt service routine, ISR). Three sources:

Handling an interrupt, step by step:

1. The device raises an interrupt request (IRQ); the CPU finishes the current instruction.
2. The CPU saves the program counter and status (on the kernel stack) and switches to kernel mode.
3. It uses the interrupt number to find the handler's address in the interrupt vector table.
4. The handler runs (usually briefly — longer work is deferred to later kernel threads).
5. The saved state is restored and the interrupted program continues, never knowing it was paused.

Priorities and nesting. Interrupts have priorities. A high-priority interrupt (e.g., a power failure or a timer) may interrupt a lower-priority handler (nested interrupts); lower-priority ones wait until higher ones finish. This is preemptive priority scheduling in miniature — the same idea you will meet for processes in Chapter 4.

Three ways to do I/O

Devices are much slower than the CPU. How does the CPU move data to and from them?

1. Programmed I/O (polling): the CPU repeatedly checks the device's status register and moves each piece of data itself. Simple, but the CPU is busy the whole time.
2. Interrupt-driven I/O: the CPU starts the operation and does other work; the device interrupts when it is ready for the next piece. Good for slow devices (keyboard), but costly for fast ones — one interrupt per small piece.
3. Direct memory access (DMA): a DMA controller moves whole blocks between the device and memory by itself and interrupts the CPU once per block.

Worked example. A 1 GHz CPU (10⁹ cycles per second) reads from a device at 4 MB/s (4,000,000 bytes/s).

• Polling, 4 bytes per poll, 400 cycles per poll: 1,000,000 polls/s × 400 = 400 million cycles/s → 40% of the CPU.
• Interrupt-driven, one interrupt per 4 bytes, 500 cycles per interrupt: 1,000,000 × 500 = 500 million cycles/s → 50% — worse than polling for this fast device!
• DMA, one interrupt per 4 KB block (4,096 bytes), 1,000 cycles to set up + 500 to handle the interrupt: 976.6 blocks/s × 1,500 = 1.46 million cycles/s → 0.15%.

For a keyboard (about 100 events/s), even polling costs only 100 × 400 = 40,000 cycles/s = 0.004% — but the CPU would have to wake up to check it constantly. Rule of thumb: interrupts for slow devices, DMA for fast ones.

Device controllers and drivers. Each device has a hardware controller with registers (status, command, data). The OS talks to it through a device driver — kernel code that knows that controller's registers and protocol, and offers a uniform interface (read, write, control) to the rest of the kernel. Drivers are the largest part of most kernels and the most common source of crashes.

Protection needs hardware

Dual-mode operation. The CPU has (at least) two modes, selected by a mode bit:

• Kernel mode (supervisor, privileged): all instructions allowed.
• User mode: privileged instructions are forbidden — for example, halting the CPU, changing the mode bit, accessing I/O ports directly, modifying memory-protection registers, disabling interrupts, or setting the timer.

If a user program tries a privileged instruction, the hardware raises an exception and the OS takes over (usually terminating the program). The only legal way from user mode to kernel mode is an interrupt, a trap (system call) or an exception — all of which jump to code chosen by the OS.

Memory protection. Each process may access only its own memory. The simplest hardware support is a pair of registers: base (first legal address) and limit (size). For every memory access in user mode the hardware checks base ≤ address < base + limit; otherwise → exception. Example: base = 30000, limit = 12000: addresses 30000–41999 are legal; 42000 traps. (Chapter 9 generalizes this with paging.)

CPU protection. A program could loop forever and never give the CPU back. The OS sets a hardware timer before giving the CPU to a program; when it expires, a timer interrupt returns control to the OS, which may switch to another program. Setting the timer is privileged. Timer interrupts are cheap: at 1,000 ticks/s and 2 µs per tick, the cost is 0.2% of the CPU (0.05% at 250 ticks/s).

System calls: the door into the kernel

A system call is the programming interface to OS services. What happens when a C or Java program writes to a file on Linux:

1. The program calls a library function (write in the C library, or FileOutputStream.write in Java, which eventually calls it).
2. The library puts the system-call number (on x86-64 Linux, write is 1) and the arguments in registers and executes the syscall instruction — a trap.
3. The CPU switches to kernel mode and jumps to the kernel's system-call entry point.
4. The kernel looks up the number in the system-call table, checks the arguments (Is this file descriptor open? Is this buffer really in the caller's memory?) and runs the service.
5. The result (or an error code such as -EBADF) is returned, and the CPU switches back to user mode.

So the answer to "which system call sends a signal to a process on Linux?" is kill (the shell command kill is a user program that calls it).

System calls are expensive. A mode switch, argument checks and cache effects make a system call typically hundreds of times more expensive than an ordinary function call. Buffering reduces the number of calls. Example: writing 1,000,000 bytes, assuming 1 µs per system call plus 1 ns per byte copied:

That is why BufferedWriter in Java and stdio in C exist: a 4 KB buffer makes this program about 800 times faster.

Booting

1. Power on → firmware (BIOS or, today, UEFI) tests the hardware (POST) and finds a boot device.
2. The boot loader (e.g., GRUB) loads the kernel image into memory.
3. The kernel initializes memory management, drivers and the scheduler, mounts the root file system.
4. It starts the first user process (PID 1, systemd or init), which starts all services and the login screen.

OS architectures

Key takeaways

• Interrupts (hardware), traps (system calls) and exceptions (faults) switch the CPU to kernel mode through the interrupt vector table; priorities allow nesting.
• I/O: polling wastes CPU, interrupts suit slow devices, DMA suits fast ones (one interrupt per block) — compute overhead as events/s × cycles/event ÷ CPU frequency.
• Dual mode + privileged instructions + base/limit registers + timer give the OS control and protection.
• A system call traps into the kernel with a number and arguments; Linux examples: fork, execve, wait4, exit, open, read, write, close, kill. System calls are costly — buffer I/O.
• Boot: firmware → boot loader → kernel → PID 1.
• Architectures: monolithic (fast), microkernel (reliable), hybrid, layered, unikernel, VM — choose by performance vs. reliability vs. size.