The UNIX software architecture: API and AUI

The stack, bottom to top

Every UNIX system is drawn the same way: hardware at the bottom, then six software layers stacked on it. Learn this figure once and every later chapter has somewhere to hang.

1. Device drivers — the only code that touches a particular piece of hardware. One driver knows how to talk to one class of device. Nothing above this layer knows the difference between a spinning disk and an SSD.
2. The kernel — the resident core, with four standing duties: process management (creation, termination, the CPU scheduler), file management (names, directories, the mapping from a name to disk blocks), main memory management (the free-space manager, and each process's address space — the memory it is permitted to touch), and disk management (the disk storage manager, and the scheduling that orders competing requests).
3. The system call interface — the narrow, guarded doorway into the kernel. open, read, write, fork, wait. User code is never given open access to kernel code, so this is the entire menu.
4. Language libraries — the C library and its equivalents. printf, fopen, malloc, strcmp. Friendlier, higher-level, and every one of them is built out of the doorway below it.
5. The shell — the command interpreter. bash, sh, csh, ksh, tcsh.
6. Applications — everything else, including all of the commands you will spend this course typing: ls, cp, grep, sort, vi.

The two interfaces that cut across it

Two names group those layers by who uses them, and getting these the right way round is worth easy marks.

The API — the Application Programming Interface — is what a program calls. It is the language libraries plus the system call interface: layers 3 and 4 together.

The AUI — the Application User Interface — is what a person drives. It is the shell, the commands, and the application programs: layers 5 and 6.

The test is not is it text or graphics, and it is not is it complicated. The test is: would you write this in a C source file, or type it at a prompt?

Worked example: placing five things on the stack

• ls — you type it at a prompt. Applications layer. AUI.
• open() — a C program calls it and it crosses into the kernel. System call interface. API.
• printf() — a C program calls it, but it is not a kernel entry point; it formats your arguments into bytes and then hands those bytes to the write system call. Language libraries. API.
• the SATA disk driver — below the kernel, wired to one class of hardware. Device driver layer. Neither — it is not an interface you are ever offered.
• bash — you type at it. Shell layer. AUI. And note that bash is itself a program written against the API: it calls fork and execve on your behalf every time you run a command. A thing's layer is where it sits, not what it is made of.

Now place four more for yourself: fopen(), grep, wait(), and the driver for your network card.

Why a library call can never be cheaper than the system call under it

This follows directly from the ordering, and it is a favourite short-answer question.

A library call runs in your own process, in user mode. If it needs the kernel to do anything — read bytes, allocate a page, write to a terminal — it must eventually issue a system call, which traps into the kernel, switches privilege level, does the work, and returns. So the library call's cost is the system call's cost plus whatever the library did on top of it. printf("%d\n", n) costs a write plus the formatting; it can never cost less than a bare write.

The obvious follow-up — then why use libraries at all — has an equally clean answer. The library is portable across systems whose system calls differ, it is far easier to use correctly, and it buys back most of the overhead by buffering, so that a hundred printf calls become one write rather than a hundred of them.