Session 01: The Software Stack

The plan of the first lecture, the demos run during it, and the points worth writing down.

This is the page used while the lecture is delivered. The full version -- the same argument in prose, with the diagrams, the reference output and the reading -- is 01-software-stack-full/.

What the lecture answers

1. What are the layers? What sits on what, from the instruction set up to a web framework, and what each layer adds.
2. What is the operating system? What it manages, what it arbitrates, and how a program asks it for something.
3. What does a layer cost? The trade-offs that decide how high in the stack to write a piece of software.
4. What kinds of software component are there? Applications and libraries, and what actually separates them.
5. How do components interact? User interfaces, APIs and protocols.

Plan

Part	Question	Demo	Figure
00. Pitch	Why should a programmer care what is underneath?	00-pitch/	--
01. Lecture map	What are we doing today?	--	the storyline
02. The software stack	What are the layers, and what does each give you?	02-software-stack/	the stack
03. The operating system	What is the kernel, and how do you talk to it?	02-software-stack/	OS and syscall API
04. Trade-offs	What do you give up by moving up or down?	04-versus/	up and down
05. Applications and libraries	What kinds of component are there?	--	apps and libs
06. Interaction	How do separate components talk?	06-software-interaction/	interaction
07. Conclusion	What should survive the week?	--	--

Storyline / Narrative

The lecture argues one thing at a time, and the figure below walks through it, step by step: the storyline.

1. The pitch: four tiny programs, thirty times apart, one character apart, fifteen times faster, doing nothing at all. Each is proof that what happens beneath your code changes what your code does.
2. Software is useful, and software is overhead. It gives you an interface and it solves your problem, and every bit of that convenience is paid for somewhere underneath.
3. Software comes in layers, each one built on top of the last.
4. Going up buys flexibility, usability, portability; going down buys performance, control, efficiency. Every piece of software sits at the height its designer chose.
5. Every layer is an interface, and every interface can be skipped. An API is a promise about what, not how, and nothing stops a program from going around it.
6. At the bottom of every stack sits the same floor: the operating system, reached through the system call API.
7. Almost every path a program takes runs through that floor, and there is no shortcut around it.
8. The OS earns its place with two things: primitives and isolation. Primitives are the resources you actually operate on: CPU as processes and threads, memory as virtual memory, I/O as file descriptors, sockets and buffers. Isolation gives each program its own protected domain, and how is next lecture's story.
9. The OS itself is nothing exotic: a library, only one that runs in a privileged domain.
10. Software comes in exactly two shapes: applications, which start, and libraries, which are called. An application can expose an API of its own, and the moment it does it starts looking like a library to whoever calls it.
11. Follow that far enough and software stacks on software: a person drives an app, that app calls libraries and other apps, and the chain repeats.
12. What should survive the week: layering buys flexibility, but never for free. The OS is the one layer every path answers to. And, overhead aside, this stuff is genuinely exciting to work with.

Points to capture

Ten things to have in your notes when you leave.

1. Software is built in layers, and each layer offers an interface to the one above: ISA, system call API, C API, language API, framework API, UI.
2. An interface is a promise about what, and it is valuable in proportion to how little it says about how.
3. The operating system does three things: manages resources, arbitrates between programs, and provides system services.
4. Its API is the system call API, and it is entered through one controlled instruction, not by jumping wherever you like.
5. The kernel is a library, not a process: it runs when a program calls it or when a device interrupts, and it runs on behalf of that program.
6. A system call costs a mode switch --- hundreds of nanoseconds against a few for a function call --- which is why libc buffers.
7. libc sits between the two: it wraps system calls and adds everything the kernel deliberately does not do.
8. Moving up the stack buys development speed, features, portability and usually safety; moving down buys control, performance and lower overhead.
9. An application has an entry point and is started; a library has an interface and is called. Both are ordinary machine code in a file.
10. Components interact through a UI (a person on the other side), an API (code in the same process) or a protocol (a different process, possibly a different machine).

Demos

Each directory below holds the commands to run and the one question to ask about the result. The sources, the reference output and the explanations are in the corresponding 01-software-stack-full/demos/ directory.

Demo	Shows
00-pitch/01-copy-string	The same string built two ways, thirty times apart.
00-pitch/02-const-char-init	One character of difference between a program that runs and one that crashes.
00-pitch/03-find-buffer-cache	The same command getting fifteen times faster by being run again.
00-pitch/04-python-string-edit	An assignment that does nothing and changes the complexity.
02-software-stack	The same message printed from five heights of the stack, counted in system calls.
04-versus	What a security guarantee costs, in nanoseconds.
06-software-interaction	Four containers, three protocols, one web page.

Slides

The deck delivered in the room is slides/software-stack-live.html, rendered from slides/software-stack-live.qmd. It is deliberately thin: the diagrams, the demo results, and nothing that is better said than read. The full deck carries the same structure with the detail filled in.