Operating Systems Roadmap

Operating Systems form the bedrock of all modern computing. Whether you’re writing application code, designing distributed systems, or optimizing database performance, understanding how operating systems work under the hood transforms you from a code user into a systems thinker. This roadmap takes you from fundamental computing concepts through to advanced OS internals — the knowledge that separates senior engineers from the rest.

By the end of this roadmap, you’ll understand how the OS schedules tasks across CPU cores, how memory gets allocated and reclaimed, how file systems organize persistent data, and how concurrent programs coordinate safely. You’ll write low-level code, analyze system calls, and debug issues that no debugger can fix.

Before You Start

• Basic programming knowledge (variables, functions, control flow)
• Familiarity with any programming language (C, Python, or JavaScript)
• Understanding of how files and directories work at a high level
• No prior systems programming experience required

The Roadmap

Timeline & Milestones

Milestone Markers

Milestone	When	What you can do
System Foundations	Weeks 1–2	Explain how a CPU executes instructions, convert between binary/hex, trace a boolean circuit to an ALU operation, and read simple x86 assembly
Process & Memory Layer	Weeks 5–8	Describe OS process lifecycle, implement scheduling algorithms, reason about virtual vs physical address translation, and analyze page fault behavior
Storage & I/O Layer	Weeks 9–10	Compare file allocation strategies, explain journaling recovery semantics, analyze disk scheduling trade-offs, and trace data path from syscall to physical disk
Concurrency & Communication	Weeks 11–12	Identify race conditions, apply mutex/semaphore patterns correctly, prevent deadlock with ordered lock acquisition, and evaluate IPC trade-offs for a given scenario
Capstone Complete	Week 17+	Build a working OS from bootloader to scheduler, profile it with perf/ftrace, and reason about kernel design decisions in real systems like Linux or FreeBSD

---

Core Topics: When to Use / When Not to Use

Process Scheduling — When to Use vs When Not to Use

When to Use	When NOT to Use
Interactive systems where response time matters — use Round Robin or MFQ to bound latency	Batch jobs with known runtimes where SJF gives optimal throughput but risks starvation
Real-time workloads with hard deadlines — use rate-monotonic or earliest-deadline-first scheduling	When overhead of context switching exceeds scheduling benefit — short-lived processes get demoted
Multi-tenant servers sharing a CPU — use fair-share scheduling to prevent one tenant from monopolizing	When task priorities are dynamic and change frequently — fixed priority causes priority inversion

Trade-off Summary: Scheduling is fundamentally a tradeoff between responsiveness (interactive), throughput (batch), and fairness (multi-tenant). No single algorithm excels at all three — your workload’s dominant concern should drive the choice. MFQ adapts reasonably well across mixed workloads but adds complexity; simpler algorithms like FCFS are predictable but can starve interactive work.

Virtual Memory — When to Use vs When Not to Use

When to Use	When NOT to Use
Running applications larger than physical RAM — use demand paging with page replacement	Embedded systems with tight real-time constraints — page faults introduce unbounded latency
Multi-process environments needing isolation — each process gets its own virtual address space	When every microsecond matters — address translation via TLB miss incurs 100+ cycle cost
Shared libraries where memory pages can be remapped read-only across processes	Systems with deterministic memory access patterns where paging is a liability

Trade-off Summary: Virtual memory provides isolation and the illusion of abundant memory at the cost of translation overhead and potential thrashing under memory pressure. For workloads that fit in RAM and demand real-time guarantees, the overhead of address translation may be unacceptable — consider direct physical addressing with fixed memory partitions instead.

File Allocation Methods — When to Use vs When Not to Use

When to Use	When NOT to Use
Sequential access patterns (log files, tape backups) — contiguous allocation gives best throughput	When files frequently change size — contiguous allocation causes external fragmentation
Read-only media (CDs, SSDs with no wear concerns) — indexed allocation minimizes seek time	Systems with strict real-time constraints — access time variance from linked traversal is unpredictable
Small embedded FAT file systems — linked allocation keeps metadata minimal	High-performance databases needing random access — indexed allocation adds indirection overhead

Trade-off Summary: Contiguous allocation is simple and fast for sequential reads but fragile under modification. Linked allocation handles dynamic growth but destroys random access performance. Indexed methods (ext2/3/4, NTFS) balance both at the cost of metadata overhead and complex recovery from crash inconsistencies.

Mutexes vs Semaphores — When to Use vs When Not to Use

When to Use	When NOT to Use
Protecting a single shared resource (queue, counter, buffer) — mutex gives ownership semantics	When multiple identical resources must be managed — counting semaphore for pool management
When you need condition variable signaling to wake a waiting thread — mutex + CV is the standard pattern	As a message-passing mechanism — semaphore count is not safe for passing data
Recursive locking scenarios — use a recursive mutex, not a counting semaphore	When you need priority inheritance to prevent priority inversion — use mutex with PI support

Trade-off Summary: Mutexes provide mutual exclusion with ownership semantics (only the owner unlocks), making them safer for single-resource protection. Semaphores are a lower-level signaling mechanism useful for resource pools and producer-consumer patterns, but they lack ownership tracking which makes misuse easier — especially when the same thread decrements a semaphore it didn’t increment.

Pipes vs Sockets vs Shared Memory — When to Use for IPC

When to Use	When NOT to Use
Related processes with parent-child relationship — anonymous pipes are zero-configuration	Unrelated processes on the same machine — use Unix domain sockets for named, bidirectional communication
High-throughput streaming data (shell pipelines, log aggregation) — pipes are kernel-buffered and fast	When sender and receiver have vastly different speeds — message queues add backpressure
When you need atomic, single-writer single-reader queues — use SOCK_DGRAM Unix domain sockets	Multi-process shared state requiring cache coherence — use mmap with MAP_SHARED, not message passing
Network IPC between machines — TCP/UDP sockets are the standard abstraction	When you need kernel-managed durability — file-backed mmap gives persistence at memory access speed

Trade-off Summary: Pipes are the simplest IPC mechanism but limited to single-direction unidirectional communication between related processes. Shared memory offers highest bandwidth but requires explicit synchronization (mutexes or atomics) to avoid race conditions. Sockets provide the most flexibility (network, Unix domain, connection-oriented or datagram) at the cost of higher kernel overhead per message.

Kernel Modules vs Userspace Services — When to Use vs When Not to Use

When to Use	When NOT to Use
Low-latency device drivers that must interact directly with hardware interrupts — kernel space is unavoidable	Complex business logic requiring large dependencies — kernel module development lacks debug tooling
When you need to intercept syscalls or modify kernel behavior — seccomp, LSM hooks require kernel context	When stability across kernel versions matters — kernel APIs change between releases, modules break
Performance-critical path where context switch overhead is unacceptable	When rapid iteration is needed — module reload requires root, crashes panic the system

Trade-off Summary: Kernel modules give direct hardware access and zero syscall overhead but carry severe risks: a bug crashes the entire system, API stability across kernel versions is not guaranteed, and development/debugging is significantly harder than userspace. For most driver needs, consider eBPF programs or user-space drivers with UIO/VFIO for direct hardware access without kernel module liability.

Resources

Books

• Operating System Concepts by Silberschatz, Galvin, Gagne — the classic OS textbook, now in its 10th edition
• Modern Operating Systems by Andrew Tanenbaum — excellent for understanding microkernel and distributed OS design
• Linux Kernel Development by Robert Love — focused, practical guide to Linux kernel internals
• Understanding the Linux Kernel by Daniel Bovet & Marco Cesati — deep dive into Linux internals
• The Design and Implementation of the FreeBSD OS — if you want to understand a real Unix-like system

Online Courses & Tutorials

• MIT 6.828: Operating System Engineering — build a mini OS from scratch, free on MIT OpenCourseWare
• University of Helsinki: Free Operating Systems Course — hands-on with Linux internals
• Linux Kernel Documentation — the official docs for kernel APIs and internals

Practice Platforms

• OSDev Wiki — comprehensive resources for building your own operating system
• xv6 — a simple Unix-like OS used in MIT and Stanford courses for learning
• QEMU — emulator for testing your OS code without real hardware

Reference

• The Linux Kernel documentation at kernel.org
• LWN.net — excellent Linux kernel news and deep technical articles
• man 2 pages for Linux system calls — run man 2 intro to explore

What’s Next

After mastering operating systems fundamentals, consider exploring these related roadmaps:

• System Design — apply OS knowledge to design large-scale distributed systems
• DevOps — leverage OS internals knowledge for infrastructure and containerization
• Distributed Systems — extend your understanding to multi-machine computing