Think Like an OS#

Authors: Shrey Patel and Jay Patel, Coconut Labs
What this is: A hands-on book on how operating systems work, from the hardware contract through kernel internals to shipping a distro, through the lens of what Coconut OS is actually building. It keeps the concepts and their prerequisites in the same place as the labs that exercise them.
Fact discipline: Every factual claim is web-verified at authoring time, with sources cited inline.


Who this book is for#

Every abstraction you use daily is a fiction the kernel maintains for you: a file, a socket, a thread, a stretch of memory that looks like it belongs to you alone. The fictions are good ones. They are not free. This book takes them apart in runnable pieces and puts them back together.

Two destinations bring people here, and the book is built for both.

You are heading toward kernel or systems work. You want to open mm/memory.c and read it instead of bouncing off it, send a patch a maintainer accepts, and know a subsystem well enough to change it. Your spine is Ch 6 to 9 (boot, syscalls, processes, scheduling), then Part III for memory, then Part V, where Coconut OS's own kernel work lives. Part IX is the workflow you will be in every day.

You are heading toward low-latency work: trading systems, market data, anything judged on its worst response rather than its average. Your question is not what the machine does. It is when. Every stall you will chase is one of the mechanisms in here, and each one has a chapter that takes it apart:

None of those six are exotic. They are ordinary machinery that most working engineers were never shown, which is why timing reads as luck until you have read them. This is not a trading book: no strategy, no microstructure, nothing about markets. It is the layer underneath, taught until you can name the mechanism behind a number instead of guessing at it. Some of the chapters named above are written and some are still outlines; the chapter list below marks which.

Where to start: Chapter 0, and do its lab rather than reading it. It ends with a Linux 6.12 kernel you compiled yourself, booting your own PID 1 in QEMU on your own machine. If you have never built a kernel, build that one before you read further. Every chapter after it lands differently.

Those two destinations are about where you are going. The three tracks below are about what you are bringing. Every chapter unfolds complex machinery into longer-but-simpler prose, and no prior kernel or CPU knowledge is assumed by the text itself. The tracks differ only in pace and which bridge sections you skip.

TrackReaderPath
A. Bridge (the curated track, described below)BS+MS CS; has taken compiler design + microprocessor/microcontroller coursework; no Linux-kernel internals yetFast bridge notes through Part I, then linear. Compiler background pays off directly in Ch 7, 24, 30.
B. Full pathAnyone in the CS industry (web dev, data, SRE, mobile) with no CPU or kernel exposureChapter 0 first, then all of Part F (the prerequisite layer), then linear. Read every "Unfolded" section; do every lab.
C. ReferenceEngineers already working on Coconut OS subsystemsJump per-chapter from the chapter list; each chapter is self-contained with a source map.

How every chapter works#

Fixed template, so you always know where you are:

  1. The problem. What breaks without this mechanism. Every OS structure is a solution; we start from the pain.
  2. Unfolded. The core idea in longer-but-simpler prose. No jargon before it is defined. This is the section that makes the book readable by someone who has never seen a page table.
  3. The real thing in Linux. Actual file paths, structs, and code paths in the 6.12 tree Coconut OS forks.
  4. Coconut tie-in. What Coconut OS changes, replaces, or adds here, cross-referenced to the high-level and low-level design documents.
  5. Lab. Runnable, QEMU-based where possible, on a macOS or Linux host. Red-then-green: you predict, you run, you compare.
  6. Bridge notes. The "if you know compilers/microcontrollers, here is the mapping" callouts for Track A.
  7. Sources. The URLs actually consulted and verified at authoring time.

The full structure#

The book runs in twelve parts.

Chapters you can read now#

Each title links straight to the chapter.

Part 0: Orientation & the lab bench#

Part F: Core fundamentals (the prerequisite layer)#

Everything the rest of the book assumes, in one place. Track B reads all of it after Chapter 0. Track A treats it as an optional refresher, with F.5 to F.7 recommended: intrusive kernel data structures and concurrency vocabulary are new even to most MS grads.

Part I: The machine beneath#

Part II: The kernel's core loop#

Chapters still in outline#

These are outlined section by section in the full syllabus. None of them is written yet. Part I and Part II pick up here where they stopped above.

Part I: The machine beneath, continued#

Part II: The kernel's core loop, continued#

Part III: Memory#

Part IV: Persistence#

Part V: Identity & capability (the Coconut heart)#

Part VI: Communication#

Part VII: The userspace contract#

Part VIII: The interaction surface#

Part IX: Building, testing, shipping#

Part X: The frontier#

Appendices#

Track A: the curated course#

Take this track if you can already read a stack frame in assembly and have written code against a microcontroller's registers and interrupts. If either of those is a no, Track B is not the slow track, it is the complete one.

What that background buys you:

Coursework you may haveDirect payoffWhere
Microprocessor/microcontrollerYou know registers, interrupts, memory-mapped I/O on small cores. Part I is a bridge, not an intro: the delta is protection (rings/ELs), virtual memory hardware, and multi-core coherence, none of which an 8051/AVR/Cortex-M ever showed youCh 1 to 5, fast
Compiler designYou know codegen, linking concepts, calling conventions. This makes Ch 7 (ABI), Ch 24 (ELF/loading), Ch 30 (toolchains) fast lanesCh 7, 24, 30
MS CS courseworkOS-course theory (you likely saw scheduling/VM at whiteboard level). The book's job is to replace whiteboard understanding with source-level + lab-verified understandingeverywhere

Recommended order and pacing (assumes roughly 5 to 8 hours a week; a "session" is one sitting with the lab done):

PhaseChaptersSessionsGoal
0. Refresh (optional)F.5, F.6, F.72Assembly reading fluency, intrusive kernel data structures, concurrency vocabulary. Skim the rest of Part F only if rusty
1. Re-ground0, 1, 2, 34Bridge micro-scale hardware knowledge to server-class x86_64/ARM64 with protection + paging
2. The spine6, 7, 8, 95 to 6Boot a kernel you built; trace a syscall end-to-end; this is the minimum "I think like an OS" bar
3. Memory truth10, 11, 12, 135Concurrency and VM: the two hardest ideas. Do not rush 10
4. The Coconut core17, 18, 19, 20, 216Everything in Part V. This is the subject matter of our kernel work
5. Round out14, 15, 16, 22, 23, 24, 25, 26, 278Persistence, IPC, userspace contract
6. Ship it30, 31, 32, 334The dev workflow you will actually live in
7. Frontier28, 29, 34, 35, 36, 376Graphics, Rust, eBPF, KVM, and the thesis chapter last

Skip rules for Track A: skip nothing in Part V or Part IX; skim any "Unfolded" section whose idea you already hold. The labs are the non-skippable part.

Fact discipline#