Operating
Systems

An Operating System (OS) is system software that manages computer hardware, software resources, and provides common services for application programs. It acts as an intermediary between users and computer hardware. Without an OS, every application would need its own device drivers, memory allocator, and hardware communication protocols, making software development nearly impossible. The OS abstracts hardware complexity, presenting programs with a clean, consistent interface. Major examples include Linux, Windows, macOS, Android, and iOS. The first OS concepts emerged in the 1950s with batch processing systems at IBM, evolving continuously to the cloud-native and microkernel designs of today.

An OS has two primary goals: convenience (making the computer easy to use) and efficiency (optimal use of hardware resources). Core functions include: Process Management (creating, scheduling, and terminating processes and threads), Memory Management (allocating, deallocating, and virtualizing memory), File System Management (organizing, storing, retrieving files and directories), I/O Management (abstracting and controlling input/output devices), Security and Protection (isolating processes, enforcing access control, preventing unauthorized operations), Networking (managing TCP/IP stack, socket interfaces, protocol implementations), and User Interface (Command-Line Interface via shell, or Graphical User Interface via desktop environment). Modern OSes balance all responsibilities while maintaining stability, security, and performance.

Operating systems are structured in fundamentally different ways. Monolithic kernels place all OS services (scheduling, memory management, file systems, device drivers) in a single large program running in privileged kernel space — fast due to no inter-process communication overhead, but less modular (Linux, original Unix). Microkernels move most services to user space, keeping only IPC, basic scheduling, and memory in the kernel — better fault isolation and formal verification potential (seL4, QNX, Minix). Hybrid kernels blend both approaches for practicality (Windows NT, macOS XNU uses a Mach microkernel wrapped in BSD Unix). Exokernels expose raw hardware directly, letting applications implement their own abstractions. Each architecture involves fundamental tradeoffs between performance, modularity, and fault tolerance.

System calls are the programmatic interface through which user programs request services from the OS kernel — the fundamental boundary between user space (Ring 3) and kernel space (Ring 0). Categories include: Process control (fork, exec, wait, exit, kill), File management (open, read, write, close, unlink, stat), Device management (ioctl, mmap), Information maintenance (getpid, gettimeofday), and Communication (pipe, socket, send, recv). When a system call is made, the CPU atomically switches from user mode to kernel mode via a software interrupt (int 0x80 on legacy x86, syscall instruction on x86-64), executes the kernel handler, then returns to user mode restoring the mode bit. System call overhead is approximately 100-300 nanoseconds — minimizing kernel crossings is critical for performance-sensitive applications.

Generation 1 (1945-55): No OS at all — machines programmed by physically rewiring circuits, then in machine code, operated entirely manually by human operators. Generation 2 (1955-65): Batch processing systems — jobs submitted on punch cards, processed sequentially without user interaction, IBM 701 with FMS. Generation 3 (1965-80): Multiprogramming and time-sharing emerged — IBM OS/360 (one OS for all IBM hardware), CTSS, Multics, and crucially Unix (Thompson and Ritchie, Bell Labs, 1969 — written in C for portability). Generation 4 (1980-present): Personal computers — CP/M, MS-DOS, Macintosh GUI (1984), Windows, and Linux (Linus Torvalds, 1991 — still the dominant server OS today). Generation 5 (present): Mobile OS (iOS 2007, Android 2008), cloud-native OS, containers (Docker 2013), orchestration (Kubernetes 2014), serverless, and unikernels.

A process is a program in execution — a dynamic, active entity with its own address space (code, data, heap, stack segments), CPU register state, open file descriptors, signal handlers, and resource accounting. The Program Counter distinguishes a running process from a static program binary on disk. Each process is represented in the kernel by a Process Control Block (PCB) containing: process state (new/ready/running/waiting/terminated), process ID (PID), parent PID, program counter, CPU registers (saved on context switch), memory management information (page table pointers), I/O status information (list of open file descriptors), and accounting info (CPU time consumed, priority, creation time). The PCB is the complete snapshot of a process. Context switching involves saving the current PCB and loading another — the kernel saves/restores all CPU registers, taking approximately 1-10 microseconds depending on hardware.

In Unix/Linux, new processes are created via fork() which creates an exact copy of the calling process. The child process is an identical clone of the parent — same code, data, heap, stack, open files — distinguished only by the return value of fork() (0 in child, child PID in parent). Copy-on-Write (CoW) optimization avoids actual memory copying: parent and child initially share all pages marked read-only; a private copy is made only when either process writes. The child typically calls exec() immediately to replace its address space with a new program (the fork-exec idiom). Windows CreateProcess() combines both steps. Process trees: init/systemd (PID 1) is the root ancestor of all Linux processes. Zombie processes have terminated but their PCB remains in the process table until the parent calls wait() to collect the exit status — if the parent dies first, the orphan is re-parented to init which reaps it.

A thread is a lightweight unit of execution within a process. Multiple threads share the process address space (code segment, data segment, heap, open files) but each maintains private state: its own stack, CPU registers, thread ID, and thread-local storage (TLS). Benefits over multi-process: thread creation is 10-100x faster than forking; threads share memory without IPC overhead; better multicore utilization. User-level threads (POSIX pthreads, Java threads using 1:1 mapping in modern JVMs): managed by the OS kernel — true parallelism on multiple cores, but kernel thread creation overhead. Green threads (Go goroutines, Erlang processes, Kotlin coroutines): scheduled by a user-space runtime (M:N mapping: M green threads on N kernel threads) — millions of lightweight concurrent tasks, stack grows dynamically (Go starts at 2KB). Race conditions occur when multiple threads access shared state without synchronization — output depends on thread scheduling order.

CPU scheduling determines which ready process gets the CPU and for how long. Evaluation metrics: CPU utilization (maximize), throughput (processes completed per time unit), turnaround time (total from submission to completion), waiting time (time in ready queue), response time (first response latency). Key algorithms: FCFS (First-Come-First-Served, non-preemptive, suffers convoy effect where short jobs wait behind long ones), SJF (Shortest Job First — theoretically optimal average waiting time but requires future knowledge), SRTF (preemptive SJF), Round Robin (preemptive, time quantum q typically 10-100ms, each process gets q time before being preempted — good response time, quantum sizing is critical), Priority Scheduling (higher priority runs first, aging prevents starvation), Multilevel Feedback Queue (processes move between queues based on behavior — I/O-bound processes get priority boost, CPU-bound processes are penalized). Linux uses CFS (Completely Fair Scheduler) based on virtual runtime tracked in a red-black tree.

Processes need to communicate and synchronize. Shared Memory: processes map the same physical memory region (shmget/shmat System V API, shm_open POSIX API) — fastest IPC (no kernel involvement after setup), but requires explicit synchronization to prevent race conditions. Message Passing: kernel-mediated send/receive operations — simpler synchronization model, slower due to kernel involvement and memory copies. Pipes: unidirectional byte stream, anonymous pipes connect related processes (ls | grep pattern), named pipes (FIFOs) connect any processes. Unix domain sockets: full-duplex, support both stream (SOCK_STREAM) and datagram (SOCK_DGRAM) semantics between processes on the same host — used by systemd, Docker, and many services for local IPC with very low overhead. Signals: asynchronous software notifications (SIGTERM for graceful termination, SIGKILL cannot be caught, SIGSEGV for segfault, SIGCHLD when child exits). D-Bus: high-level IPC system used extensively in Linux desktop environments.

A race condition occurs when multiple processes or threads access shared data concurrently and the final result depends on the execution order — a non-deterministic bug that is notoriously difficult to reproduce and debug. The critical section is the code segment accessing shared resources (shared variables, files, hardware). A correct solution must satisfy three conditions: Mutual Exclusion (only one process executes in its critical section at any time), Progress (if no process is in its critical section, the decision on who enters next cannot be postponed indefinitely), and Bounded Waiting (there is an upper bound on the number of times other processes may enter their critical sections after a process has requested entry). Software-only solutions: Peterson's Algorithm (two processes, uses turn variable and flag[] array), Dekker's Algorithm (first software solution, complex). Hardware solutions: TestAndSet, CompareAndSwap — atomic read-modify-write operations that form the foundation of all modern synchronization primitives.

A Mutex (mutual exclusion lock) is the most basic synchronization primitive: lock() acquires it (blocks if already held), unlock() releases it. Spinlocks use busy-waiting (continuously checking the lock) — appropriate only for very short critical sections on multicore where sleeping would be more expensive than spinning. Blocking mutexes put the thread to sleep if the lock is unavailable, waking it when signaled. A Semaphore (Dijkstra, 1965) is an integer with two atomic operations: wait(S) decrements (blocks if S would become negative) and signal(S) increments (wakes a blocked process). Binary semaphore (S=1) = mutex. Counting semaphore controls a resource pool. Classic problems: Producer-Consumer with bounded buffer (semaphores: empty, full, mutex), Readers-Writers (multiple concurrent readers vs exclusive writer), Dining Philosophers (5 philosophers alternating thinking and eating with shared forks — demonstrates deadlock and starvation). Monitors (Hoare/Brinch Hansen): high-level synchronization construct combining data, procedures, and condition variables — implemented as Java synchronized methods and wait()/notify().

A deadlock is a situation where a set of processes are permanently blocked because each is waiting for a resource held by another in the set. Coffman's four necessary conditions (all must simultaneously hold for deadlock): Mutual Exclusion (at least one resource held non-shareably), Hold and Wait (a process holds at least one resource while waiting for additional resources held by others), No Preemption (resources can only be released voluntarily by the holding process), Circular Wait (there exists a circular chain P1 ? R1 ? P2 ? R2 ? P1 of processes waiting for resources). Resource Allocation Graph (RAG): bipartite graph with process nodes (circles), resource nodes (rectangles), request edges (P ? R), and assignment edges (R ? P). If the RAG has no cycle, no deadlock. If a cycle exists: deadlock if each resource has one instance; possibly deadlock with multiple instances (requires detection algorithm).

Prevention: ensure at least one Coffman condition never holds. Deny Hold-and-Wait by requiring processes to request all resources atomically upfront (low utilization). Allow preemption by forcibly removing resources from processes. Impose a total ordering on all resource types, requiring processes to request resources in strictly increasing order (prevents Circular Wait). Avoidance: Banker's Algorithm (Dijkstra) — before allocating any resource, check whether the resulting state is safe (a sequence exists where all processes can complete to termination). Requires knowing maximum resource requirements upfront — practical for systems where this is known. Detection and Recovery: periodically run a deadlock detection algorithm (similar to safety check). Recovery options: terminate all deadlocked processes (expensive), terminate one at a time until cycle broken (choosing victim by cost criteria), or preempt resources (rollback process to safe state). Most general-purpose OSes (Linux, Windows) take the ostrich approach: assume deadlocks are sufficiently rare that ignoring them is more efficient than the constant overhead of prevention/detection.

Traditional locking has fundamental problems: priority inversion (low-priority process holds lock needed by high-priority process — famously caused the Mars Pathfinder reset bug in 1997), convoying (many processes pile up behind a slow lock holder), deadlock, and poor scalability under contention. Lock-free data structures use atomic hardware instructions (Compare-And-Swap CAS, LL/SC on RISC) to provide progress guarantees without traditional locks. Lock-free guarantees at least one thread makes progress (others may retry). Wait-free guarantees every thread completes its operation in bounded steps — strongest guarantee, hard to implement. Examples: lock-free stack (Treiber stack), Michael-Scott lock-free queue (used in Java ConcurrentLinkedQueue), lock-free hash tables. Software Transactional Memory (STM): treat memory operations as database transactions — optimistically execute, validate on commit, retry on conflict. Implemented in Haskell GHC STM, Clojure's STM. Hardware Transactional Memory (Intel TSX, IBM POWER8): execute code in hardware transaction, abort on conflict.

The memory hierarchy exploits locality: registers (<1ns, bytes), L1 cache (1-4ns, 32-64KB per core), L2 cache (4-12ns, 256KB-1MB), L3 cache (10-50ns, 4-64MB shared), DRAM (50-100ns, 4-128GB), NVMe SSD (100µs-1ms, TBs), HDD (5-15ms). Each process has a virtual address space (0 to 264 on 64-bit systems) completely independent of physical memory layout — this isolation is the fundamental security and stability primitive of the OS. The CPU generates virtual (logical) addresses; the Memory Management Unit (MMU) hardware translates them to physical addresses. The OS maintains the translation mapping (page tables), the MMU performs the lookup efficiently in hardware, and the Translation Lookaside Buffer (TLB) caches recent translations. This architecture allows memory isolation (processes cannot access each other's memory), overcommit (allocate more virtual memory than physical), and flexible memory layout.

Paging divides physical memory into fixed-size frames (typically 4KB) and virtual address spaces into equal-size pages. The OS maintains a per-process page table mapping page numbers to frame numbers. Virtual address translation: split virtual address into page number p and offset d; look up page table entry for p to get frame f; physical address = f concatenated with d. The TLB caches recent page table entries — a hit costs ~1 cycle overhead; a miss requires a hardware page table walk (2-4 memory accesses for 4-level x86-64 page tables), costing 10-50 cycles. TLB hit ratios exceed 99% due to temporal and spatial locality. Multi-level page tables (4-level on x86-64: PGD ? PUD ? PMD ? PTE) avoid allocating full page tables for sparse address spaces — a full single-level page table for a 48-bit virtual address space would be 512GB! Huge pages (2MB, 1GB) reduce TLB pressure by covering more memory per entry — critical for databases and scientific computing.

Virtual memory allows a process to use more address space than physical RAM by backing virtual pages with swap space on disk. Demand paging loads pages only when accessed — a page fault occurs when the CPU accesses a page not present in RAM, triggering the OS page fault handler which locates the page on disk or in swap, reads it into a free frame, updates the page table, and restarts the faulting instruction. Major page faults (require disk I/O) cost ~8-10ms — catastrophic for performance if frequent. Minor page faults (page in memory but page table not updated, or zero-fill needed) cost ~1µs. Effective access time = (1-p) × memory_time + p × page_fault_time. Copy-on-Write after fork(): parent and child share all pages as read-only; a private copy is made per-page only when a write occurs — makes fork() essentially free regardless of process size. Thrashing occurs when the working set (actively used pages) exceeds available RAM, causing continuous page faults that consume all CPU time in the pager.

When a page fault occurs with no free frames, the OS must evict a victim page. Optimal (OPT/Bélády's algorithm): replace the page that will not be used for the longest time in the future — theoretically minimal page faults but impossible to implement (requires future knowledge); used only as a performance benchmark. FIFO: evict the oldest loaded page — simple, poor performance, paradoxically causes more page faults with more frames in some cases (Bélády's anomaly). LRU (Least Recently Used): evict the page not accessed for the longest time — excellent approximation of OPT based on temporal locality; expensive to implement exactly (requires timestamps or a doubly linked list + hash map for O(1) operations). Clock (Second Chance): circular buffer of pages, each with a reference bit; when a victim is needed, scan clockwise setting reference bits to 0 and evicting the first page with bit=0 — efficient LRU approximation. Linux uses a two-list LRU (active list + inactive list) with reference bit tracking, combined with memory pressure-based reclaim via the kswapd kernel thread.

Segmentation divides the address space into variable-size logical units (code segment, data segment, stack, heap, shared libraries) each with a base address, size limit, and protection attributes. Modern x86-64 largely abandons hardware segmentation (all segment bases are 0 in 64-bit mode — flat address space) in favor of pure paging. Memory protection is enforced via page table entry bits: Present (page in physical memory), Read/Write (can the page be written?), User/Supervisor (accessible from user mode?), NX/XD (No-Execute bit — prevents executing data pages, mitigates shellcode injection). Address Space Layout Randomization (ASLR): randomizes the base addresses of stack, heap, mmap regions, and shared libraries at each execution — makes it much harder for attackers to predict addresses for ROP/JOP attacks. Stack canaries (GCC -fstack-protector): a random value placed between local variables and the return address; if overwritten by a buffer overflow, the OS detects it before the function returns. Kernel Page Table Isolation (KPTI): Meltdown mitigation that maps minimal kernel data into user-space page tables.

A file is a named, persistent, ordered collection of information stored on secondary storage — the fundamental abstraction that makes data outlast the processes that create it. File attributes (stored in metadata, not in file data): name, inode number (unique identifier within a filesystem), type (regular, directory, symbolic link, block/character device, FIFO, socket), size in bytes, block count, owner UID and GID, permission bits (rwxrwxrwx), and three timestamps (atime: last access, mtime: last content modification, ctime: last metadata change). Directory structures: single-level (all files in one directory — primitive), two-level (per-user directories), tree-structured (hierarchical, absolute paths from root /, relative paths from current directory), acyclic-graph (hard links: multiple directory entries pointing to the same inode; soft/symbolic links: a file containing a path string), general graph (can create cycles, requires garbage collection). In Unix/Linux, the Virtual File System (VFS) layer provides a uniform API (inode, dentry, superblock, file operations) that all concrete filesystem implementations must satisfy.

On-disk structures of a typical Unix filesystem: boot block (sector 0: bootloader or boot record), superblock (filesystem metadata: magic number, block size, total blocks, total inodes, free block bitmap, free inode bitmap, root inode number — critical structure, duplicated), inode table (fixed array of inodes, one per file — contains all file metadata and block pointers), and data blocks (actual file content). The Unix inode stores 12 direct block pointers (file data up to 12×4KB = 48KB accessible in 1 disk access), 1 single-indirect pointer (pointer to block of 1024 pointers ? 4MB in 2 accesses), 1 double-indirect (pointer to block of indirect blocks ? 4GB in 3 accesses), and 1 triple-indirect (16TB in 4 accesses). Directory implementation: linear list of (inode number, filename) pairs, hash table for O(1) lookup, or B-tree for large directories (HFS+). Free space management: bitmap (one bit per block, scans fast with CPU bitwise operations), linked free list (simple but slow for large blocks), extent-based tracking.

A file system must remain consistent even after unexpected power loss or crashes during multi-step operations. A simple file creation requires: allocating an inode, updating the inode bitmap, writing directory data, updating directory's mtime — if power fails between any two steps, the filesystem is corrupted. fsck (filesystem check) repairs corruption but requires scanning the entire disk — takes hours on large disks. Journaling (write-ahead logging): before making any changes to the filesystem, write a journal entry (transaction) describing the changes to a dedicated circular log area on disk. On crash recovery, replay journal entries — takes seconds. Metadata journaling (ext3, ext4 default): only journal metadata changes (inodes, directories, bitmaps) — faster, but data can be corrupted. Full data journaling: journal data blocks too — safest but slowest. Ordered journaling: data blocks written to disk before committing metadata journal — good compromise. Log-Structured File Systems (LFS): entire disk is a circular log — all writes are sequential, read performance uses an inode map, garbage collection required for old versions. ZFS and Btrfs use copy-on-write (CoW) semantics instead of journaling — always write to new locations, then update pointers atomically.

ext4 (Linux default on most distributions): extents replace per-block indirect pointers (an extent is a contiguous run of blocks, described by start + length — dramatically reduces metadata for large files), delayed allocation (write data to page cache first, allocate blocks at flush time to improve contiguity), persistent preallocation, journal checksums, 48-bit block addressing (1 exabyte volume limit), HTree directories (htree = B-tree variant for O(log n) directory operations). Btrfs (B-tree FS, Linux): CoW semantics eliminate the need for journaling, integrated volume manager (RAID 0/1/5/6/10, span multiple devices), checksums on all data and metadata (detects silent corruption), instant atomic snapshots, subvolumes (independent filesystem trees), online defragmentation and resize, compression (zstd, lzo, zlib), send/receive for efficient backups. ZFS (OpenZFS): similar to Btrfs but more mature — 128-bit addressing, always-consistent (no fsck needed), end-to-end checksums with RAID-Z parity repair, deduplication, extremely large datasets. NTFS (Windows): Master File Table (MFT) where every file is an attribute tree, journal ($LogFile), sparse files, alternate data streams, EFS encryption, compression, per-file and per-folder permissions with inheritance.

RAID (Redundant Array of Independent Disks) provides performance improvement and/or fault tolerance by combining multiple physical disks. RAID 0 (striping): data split across disks in interleaved chunks — doubles throughput (in theory), zero redundancy — any single disk failure destroys all data. RAID 1 (mirroring): complete duplicate on two disks — reads can be served from either disk (parallelism), survives any single disk failure, 50% storage efficiency. RAID 5 (distributed parity): data and parity striped across =3 disks — parity allows reconstruction of any single failed disk (XOR of all other disks), good read performance, write penalty (must update parity on every write — read-modify-write cycle), 1-(1/N) efficiency. RAID 6: two independent parity blocks per stripe, survives 2 simultaneous disk failures — critical for large disk counts where RAID 5 rebuild I/O risks a second failure. RAID 10 (1+0): mirror pairs, then stripe — best performance and redundancy combination, 50% efficiency, expensive. Software RAID (Linux mdadm) vs hardware RAID controller (battery-backed write cache, faster rebuild). ZFS RAID-Z avoids the RAID 5 write hole through CoW semantics.

I/O devices are classified as: block devices (disk drives, SSDs, USB drives — transfer data in fixed-size blocks, randomly addressable, mountable with a filesystem), character devices (keyboards, mice, serial ports, terminals — stream of bytes, not seekable), and network devices (Ethernet, WiFi — neither block nor character; accessed via socket interface). Devices communicate with the CPU via device controllers containing registers the software can read/write. Port-mapped I/O (PMIO): dedicated I/O address space accessed with special IN/OUT CPU instructions (legacy x86). Memory-mapped I/O (MMIO): device registers mapped into the physical address space, accessed with regular load/store instructions — simpler programming model, used by virtually all modern devices (PCIe devices, ARM SoCs). Device registers: data register (input/output data buffer), status register (device busy, data ready, error flags), control register (commands to the device). The OS abstracts all device types behind a uniform file-like interface through the device driver subsystem.

Three I/O methods in increasing efficiency: Programmed I/O (busy-waiting/polling) — CPU continuously checks status register until operation completes — wastes CPU cycles, only appropriate for very fast operations or embedded systems. Interrupt-driven I/O — CPU initiates I/O and continues doing other work; device raises a hardware interrupt signal when done; CPU saves state, jumps to the Interrupt Service Routine (ISR) in the interrupt vector table, processes the completion, then resumes interrupted work — efficient for slow devices. Direct Memory Access (DMA) — for bulk transfers, the DMA controller moves data directly between device and RAM without involving the CPU for each byte; CPU programs the DMA controller (source address, destination address, byte count, direction), DMA performs the transfer, interrupts CPU when done — essential for disk I/O, network, GPU, audio at high bandwidth. Modern systems use multiple DMA channels and I/O Memory Management Units (IOMMUs, Intel VT-d, AMD-Vi) to restrict which physical memory addresses each DMA-capable device can access, preventing DMA-based attacks.

A device driver is the software layer implementing a standardized kernel interface for a specific hardware device. The driver translates generic OS requests (read, write, ioctl) into device-specific commands and register manipulations. Linux kernel device driver interfaces: character device drivers register via cdev_add() implementing struct file_operations (open, release, read, write, llseek, ioctl, mmap), block device drivers register a request queue and gendisk, network drivers register net_device and implement ndo_start_xmit(). Linux supports loadable kernel modules (LKMs) — drivers compiled as .ko files loaded at runtime with insmod/modprobe without rebooting. The Linux driver model (kobject, kset, bus, device, driver) provides a unified device tree accessible via sysfs (/sys/bus/pci/devices/...). The I/O subsystem above drivers provides: I/O scheduling (reorder block requests for efficiency), buffering (single/double/circular buffers absorb speed mismatches), caching (page cache holds recently accessed disk data in RAM — dramatically reduces disk I/O), spooling (print queue), error handling, and power management.

Unix I/O models from simplest to most scalable: Blocking I/O (default) — process blocks until I/O completes, woken by kernel when data is ready — simple to program, one thread per connection required. Non-blocking I/O (O_NONBLOCK flag) — returns EAGAIN immediately if I/O cannot complete — requires polling, wastes CPU. I/O Multiplexing: select() and poll() — process blocks waiting on multiple file descriptors simultaneously, returns when any are ready — N connections with 1 thread; select() limited to 1024 fds, O(N) per call. epoll (Linux 2.6): event-driven interface maintaining a set of watched fds in the kernel; epoll_wait() blocks until any event fires, returns only the ready fds — O(1) per call, scales to hundreds of thousands of connections. Foundation of nginx, Node.js, Redis, Netty. Signal-driven I/O (SIGIO): process registers handler, kernel sends signal when I/O ready. POSIX AIO: fully asynchronous, process continues immediately, callback on completion. io_uring (Linux 5.1+): shared submission and completion ring buffers between user space and kernel — batch I/O operations, zero-copy, zero-syscall steady-state operation; revolutionary performance for storage and network I/O.

The storage interface has been a major performance bottleneck. Traditional HDD uses SATA (up to 6Gbps) with AHCI (Advanced Host Controller Interface): single command queue of 32 entries, designed for spinning disk latency characteristics. NVMe (NVM Express): protocol designed from scratch for flash — up to 65,535 command queues each with 65,535 commands (vs AHCI's single queue of 32), directly attached to PCIe (4.0 x4 = 7.88 GB/s), latency 20-100µs (vs HDD 5-15ms). NVMe-oF (NVMe over Fabrics): access NVMe devices over high-speed networks (InfiniBand/RDMA, RoCE, TCP) with near-local latency — enabling disaggregated storage architectures where flash is pooled in a storage fabric. Persistent Memory (Intel Optane PMEM, now discontinued but architecturally influential): byte-addressable persistent memory on the memory bus — access via CPU load/store like DRAM (~300ns latency) with persistence like flash, used with DAX (Direct Access) mode in Linux/Windows to bypass page cache entirely, enabling new storage architectures. CXL (Compute Express Link) is the emerging standard for memory pooling and expansion over PCIe 5.0.

Hardware-enforced privilege separation is the foundation of OS security. x86 defines four protection rings: Ring 0 (kernel mode) has unrestricted access to all hardware, all instructions, and full physical address space; Ring 3 (user mode) has restricted access — certain instructions (HLT, IN/OUT, CLI/STI) are privileged and cause a General Protection Fault if executed by user code. The Current Privilege Level (CPL) is stored in bits 0-1 of the CS segment register. User processes can only access kernel services via controlled entry points (system calls, gates). Hypervisors (VMware, KVM, Xen) use hardware virtualization extensions — Intel VT-x adds VMX root mode (Ring -1) where the hypervisor runs with higher privilege than the guest OS kernel, enabling full OS-in-OS isolation. ARM TrustZone creates a 'Secure World' and 'Normal World' hardware partition, with the Secure Monitor (EL3) being the highest privilege level — used for secure storage, cryptographic key management, and trusted execution environments (TEEs) on mobile SoCs.

Discretionary Access Control (DAC): resource owners control access. Unix DAC: owner/group/other permission bits (rwxrwxrwx, stored in inode), setuid/setgid bits (process runs with file owner's privileges — e.g., /usr/bin/passwd needs root access to /etc/shadow), umask (default permission mask). POSIX ACLs extend Unix permissions with per-user and per-group entries. Mandatory Access Control (MAC): system-wide mandatory policy overrides DAC — a process cannot grant permissions it doesn't itself have (Bell-LaPadula model for confidentiality, Biba for integrity). SELinux (Security-Enhanced Linux, NSA): labels (security contexts) on every process and file, type enforcement policy rules (e.g., httpd_t can read httpd_sys_content_t but not shadow_t), multiple policy types (targeted, strict, MLS). AppArmor (Ubuntu/SUSE): path-based MAC, per-application profiles defining allowed files and capabilities — simpler than SELinux. RBAC: permissions assigned to roles (admin, auditor, operator), users assigned to roles — maps better to organizational structures. Linux Capabilities: fine-grained privileges replacing all-or-nothing root (CAP_NET_BIND_SERVICE to bind port <1024, CAP_SYS_PTRACE to trace processes, CAP_DAC_OVERRIDE to bypass file permissions).

Stack buffer overflow: writing beyond a stack buffer overwrites the saved return address — attacker redirects execution to shellcode or existing code (return-to-libc). Mitigations: stack canaries (random value between local vars and return address, checked before return — GCC -fstack-protector-all), ASLR (randomize stack base address each run), NX/DEP (No-Execute/Data Execution Prevention — mark stack non-executable, prevent shellcode execution). Return-Oriented Programming (ROP): chains existing code 'gadgets' (sequences ending in RET) from the binary itself to bypass NX — requires knowing addresses (bypassed by info leaks defeating ASLR). Use-after-free: accessing a heap pointer after free() — type confusion, arbitrary read/write, code execution — mitigated by tcache quarantine (delay reuse), safe unlinking, CFI (Control Flow Integrity). Format string vulnerabilities: %n in printf() writes to arbitrary memory. Dirty COW (CVE-2016-5195): race condition in Linux copy-on-write — privilege escalation without memory allocation. OS mitigations layer: KASLR (Kernel ASLR), SMEP (Supervisor Mode Execution Prevention), SMAP (Supervisor Mode Access Prevention), CFI (Clang/LLVM Control Flow Integrity), KPTI (Kernel Page Table Isolation for Meltdown).

Linux containers use kernel features to create isolated execution environments without full virtualization overhead. Linux namespaces isolate specific global resources: PID namespace (process IDs, init is PID 1 inside), Network namespace (interfaces, routing tables, iptables rules), Mount namespace (filesystem mount points), UTS namespace (hostname and domain name), IPC namespace (System V IPC, POSIX message queues), User namespace (UID/GID mapping — allow non-root to create containers, map container root to unprivileged host UID), Cgroup namespace (isolate cgroup hierarchy view), Time namespace (different time offsets). Linux cgroups (Control Groups) v2: hierarchical resource control — limit CPU shares and quota, memory hard limit (with OOM killer), block I/O bandwidth, network priority, number of processes. Seccomp (Secure Computing Mode): syscall filtering using BPF filters — Docker default profile blocks 44 dangerous syscalls (ptrace, mount, kexec_load). Combining namespaces + cgroups + seccomp + capabilities + pivot_root gives Docker its isolation model, all without a separate kernel — hence 'OS-level virtualization'.

Trusted Computing provides hardware-rooted security guarantees. TPM (Trusted Platform Module, ISO/IEC 11889): secure cryptoprocessor on the motherboard — persistent key storage, random number generation, Platform Configuration Registers (PCRs) that record SHA-256 hashes of each boot component. PCR extends hash: PCR[n] = SHA256(PCR[n] || new_measurement). Sealed secrets: encryption key sealed to a specific PCR state — decryptable only when the same software chain has booted. UEFI Secure Boot: firmware verifies bootloader signature against MOK (Machine Owner Key) database ? shim (Microsoft-signed) ? GRUB ? Linux kernel (signed with distro key) — each link verifies the next, preventing bootkit persistence. Intel TXT (Trusted Execution Technology) and AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging): hardware memory encryption and integrity for confidential VMs — even the hypervisor and cloud operator cannot read guest memory. Used by Azure Confidential Computing, AWS Nitro Enclaves, Google Confidential VMs. The attestation protocol allows a remote party to cryptographically verify what code is running in a TEE.

A hypervisor (Virtual Machine Monitor, VMM) creates and manages virtual machines — abstract representations of complete computers. Type 1 (bare-metal) hypervisors run directly on hardware without a host OS: VMware ESXi, Microsoft Hyper-V, Xen (open source, used by AWS EC2), KVM (Linux Kernel-based Virtual Machine — a Linux kernel module making Linux itself a Type 1 hypervisor). Type 2 hypervisors run as applications on a host OS: VMware Workstation, Oracle VirtualBox, QEMU (open source, used with KVM). Full virtualization: guest OS runs completely unmodified — Intel VT-x/AMD-V hardware extensions cause sensitive instructions to trap to the hypervisor. Paravirtualization: guest kernel is modified to call hypercalls instead of privileged instructions — better performance but requires OS changes (Xen PV, virtio device model). Hardware-assisted virtualization with Intel EPT (Extended Page Tables) / AMD NPT (Nested Page Tables): hardware handles guest physical to host physical address translation, eliminating shadow page table overhead and dramatically improving performance.

KVM (merged into Linux mainline in kernel 2.6.20, 2007) provides the virtualization infrastructure as a kernel module (/dev/kvm character device). QEMU provides device emulation (virtual disks, network interfaces, display adapters). Together KVM+QEMU provide efficient x86 virtualization: guest runs in VMX non-root mode (introduced by VT-x) at near-native speed for non-privileged code; when guest executes privileged operations (writes to control registers, accesses unmapped devices, page table modifications), a VMEXIT occurs transferring control to the hypervisor. KVM handles VMEXIT events in kernel space when possible, delegating device emulation to QEMU user space for complex cases. virtio: paravirtual device framework with ring buffer-based I/O — guest virtio driver communicates directly with QEMU virtio backend via shared memory, dramatically better I/O performance than full device emulation. vhost: moves virtio processing from QEMU user space into the kernel, reducing context switch overhead for high-throughput network I/O. VFIO: direct device assignment lets VMs access physical devices (GPU, NIC) without any software I/O path.

Containers vs VMs: VMs virtualize hardware (each VM has a complete OS kernel, occupies 512MB-4GB memory, boots in 30-60 seconds), containers share the host OS kernel (each container is a group of processes in namespaces, typically 50-500MB, starts in milliseconds). Containers have a smaller isolation boundary (shared kernel = larger attack surface for kernel exploits) but dramatically better density. Docker: the container platform that made containers mainstream. Docker image: layered union filesystem (OverlayFS) where each RUN/COPY instruction creates an immutable layer; layers are content-addressed (SHA256) and shared across images and containers saving disk space. Docker registry (Docker Hub, ECR, GCR): stores and distributes images. Docker architecture: Docker CLI ? Docker daemon (dockerd) ? containerd (container runtime management) ? runc (OCI-compliant container executor using namespaces+cgroups). Docker Compose: multi-container applications. Security considerations: never run containers as root, use read-only root filesystems, drop all capabilities and add back only needed ones, use seccomp profiles, scan images for vulnerabilities.

Kubernetes (K8s, Google 2014, now CNCF) orchestrates containerized applications across clusters of machines. Core abstractions: Pod (smallest deployable unit, 1+ tightly coupled containers sharing a network namespace and volumes), ReplicaSet (maintains N identical pod replicas), Deployment (declarative pod template + scaling + rolling updates + rollback), Service (stable network endpoint for a set of pods using label selector, load balances across pods), Namespace (virtual cluster partition), ConfigMap/Secret (externalize configuration and credentials), PersistentVolume/PVC (persistent storage abstraction). Control plane: kube-apiserver (REST API, all state stored in etcd), etcd (distributed key-value store, Raft consensus), kube-scheduler (assigns pods to nodes based on resource requests, affinity/anti-affinity, topology spread), kube-controller-manager (reconciliation loops for Deployments, StatefulSets, etc.), cloud-controller-manager (cloud provider API integration). Node components: kubelet (ensures pod containers running per spec), kube-proxy (maintains iptables/IPVS rules for Service networking), container runtime (containerd, CRI-O). Helm: package manager for Kubernetes applications.

Serverless computing abstracts away server management entirely — developers deploy code, the platform manages all infrastructure. AWS Lambda: functions run in Firecracker microVMs (KVM-based, <125MB memory overhead, <150ms cold start), billed per 100ms invocation, scales from 0 to thousands of instances automatically. Firecracker (open source by AWS): purpose-built microVM manager — minimalist virtual machine for Lambda and Fargate, stripped-down virtio devices, no BIOS, 5-second startup, very small footprint — achieves VM-level isolation with container-like density. WebAssembly (WASM) as an alternative execution model: platform-independent bytecode with a well-defined sandbox model (no ambient authority), near-native performance via JIT compilation, sub-millisecond cold starts. Cloudflare Workers (V8 isolates), Fastly Compute@Edge (WASM), Fermyon Spin: serverless WASM platforms. eBPF (extended Berkeley Packet Filter): run verified, sandboxed programs directly in the Linux kernel — attach to tracepoints, kprobes, XDP hooks — used by Cilium for zero-overhead container networking, Falco for runtime security, Pixie for observability. eBPF is architecturally transforming what the OS kernel does and how it can be extended safely.

The Completely Fair Scheduler (CFS, merged Linux 2.6.23, Con Kolivas/Ingo Molnár, 2007) replaced the O(1) scheduler with a design based on a single concept: give every process a fair share of CPU time proportional to its weight (derived from nice value: nice -20 to +19 maps to weights 88761 to 15). CFS tracks vruntime (virtual runtime) for each runnable process — vruntime accumulates at a rate inversely proportional to the process's weight, so high-priority processes age slower. The scheduler always runs the process with the minimum vruntime — implemented as the leftmost node in a per-CPU red-black tree (O(log n) insert/remove, O(1) minimum lookup). No fixed timeslice: the scheduler recalculates at each context switch based on number of runnable processes and system load. CFS group scheduling (kernel config FAIR_GROUP_SCHED): schedule groups via cgroup CPU controller — ensures equal time between groups (containers, users) before distributing within groups. The Earliest Eligible Virtual Deadline First (EEVDF) scheduler, merged in Linux 6.6, adds latency-sensitivity targeting to CFS for better interactive responsiveness.

POSIX real-time scheduling policies in Linux: SCHED_FIFO (static priorities 1-99, highest-priority runnable task runs until it blocks or yields — never preempted by lower priority), SCHED_RR (round-robin within same priority level — adds timeslice between equal-priority tasks), SCHED_DEADLINE (EDF-based, task specifies runtime/deadline/period, kernel enforces admission control to prevent overload — Linux 3.14+). Hard real-time requirements demand bounded worst-case latencies. The PREEMPT_RT patchset (largely merged into mainline by Linux 6.x) converts Linux into a fully preemptible kernel: converts spinlocks to sleeping mutexes, makes interrupt handlers run as kernel threads (threaded interrupts), eliminates non-preemptible sections — achieves deterministic latencies of 50-200µs on standard hardware, good enough for industrial control. Dedicated RTOSes for hard real-time: FreeRTOS (embedded IoT, AWS manages it), VxWorks (aerospace, Tesla Autopilot), QNX (automotive ADAS, BlackBerry), RTEMS (NASA spacecraft), Zephyr RTOS (Linux Foundation, IoT wearables). seL4 provides formally verified real-time guarantees.

SMP (Symmetric Multiprocessing) scheduling: all CPUs run the OS scheduler and can execute any process. Per-CPU runqueues (Linux CFS): each CPU has its own runqueue — eliminates runqueue lock contention, but requires load balancing. Linux scheduler load balancing: hierarchical scheduling domains (CPU core ? socket ? NUMA node); load balancer runs periodically (triggered by idle CPU or imbalance detection) and migrates tasks between runqueues, respecting cache affinity (avoid migrating tasks with warm caches unless imbalance is significant). NUMA (Non-Uniform Memory Access): on multi-socket servers, each socket has directly-attached memory (local, fast ~80ns) and must go over QPI/Infinity Fabric to access remote socket memory (remote, slower ~160ns). Linux NUMA balancer (automatic NUMA balancing, kernel 3.8+): periodically unmaps process pages, detects which NUMA node the process is actually accessing (via page fault profiling), migrates process or memory to be collocated. CPU affinity: taskset command and sched_setaffinity() system call bind processes to specific CPU sets — used to isolate latency-sensitive workloads (real-time, high-frequency trading) from OS noise.

OS scheduling decisions interact profoundly with CPU microarchitecture. TLB shootdowns: when modifying page tables for a running process on a multicore system, other CPUs caching the affected translations must be invalidated via inter-processor interrupts (IPIs) — expensive synchronization cost that makes page table modifications costly. Simultaneous Multithreading (SMT / Intel HyperThreading): each physical core exposes 2 logical CPUs sharing execution units, L1/L2 cache, and TLB. OS must schedule complementary threads (one memory-bound, one compute-bound) on sibling threads and be aware that 2 runnable threads on the same physical core may perform worse than 1 thread on an idle physical core. The scheduler topology representation distinguishes physical cores from logical CPUs. CPU frequency scaling (DVFS): Linux CPUFreq subsystem with governors — schedutil governor (default, modern) integrates with CFS utilization signals to set CPU frequency proportional to actual load — better energy efficiency than performance or powersave governors. Intel Thread Director (12th gen+) / ARM DynamIQ: hardware provides per-thread performance hints to the OS scheduler, enabling intelligent assignment of workloads to efficiency vs performance cores.

Systematic OS performance analysis: USE Method (Utilization, Saturation, Errors) for resources; RED Method (Rate, Errors, Duration) for request-driven services (Brendan Gregg). Key Linux performance tools: vmstat/iostat/mpstat (system-wide CPU, disk, memory statistics), top/htop/atop (per-process resource usage), perf stat (hardware performance counters — CPU cycles, cache misses, branch mispredictions per process), perf record + perf report (CPU profiling with call stacks), flamegraph.pl (Brendan Gregg's visualization of profiling data — wide horizontal bars indicate hot code paths), strace (system call tracing via ptrace, high overhead), ftrace (built-in kernel function tracer, low overhead), bpftrace / BCC tools (eBPF-based dynamic tracing — execsnoop, opensnoop, tcplife, off-cpu analysis). /proc filesystem virtual FS exposes kernel state: /proc/PID/maps (process memory map), /proc/interrupts (per-CPU interrupt counts), /proc/net/tcp (TCP socket table), /proc/schedstat (scheduler statistics). perf c2c detects cache line contention ('False Sharing') between CPU cores — a common multicore performance bug.

The OS implements the TCP/IP network stack in the kernel, providing a clean socket API to applications. Packet receive path: NIC receives Ethernet frame ? DMA into pre-allocated ring buffer in kernel memory ? raises hardware interrupt ? kernel NET_RX softirq ? netif_receive_skb() ? passes sk_buff (socket buffer) up through network layers ? IP layer (routing decision, NAT, netfilter hooks) ? TCP layer (reassembly, flow control, delivery to socket receive buffer) ? wake up blocked user process (or deliver epoll event). sk_buff is the central data structure representing a network packet traversing the kernel stack — contains payload pointer and length, headers at various layers (added/removed via push/pull without copying), device reference, and socket reference. The NAPI (New API) polling mechanism prevents interrupt storms at high packet rates: after the first interrupt, the driver is put in polling mode (softirq repeatedly polls for more packets) until the backlog is drained — eliminates interrupt overhead at high throughput while maintaining low latency at low rates.

The BSD socket API (4.2BSD, 1983) is the universal network programming interface. Core system calls: socket(domain, type, protocol) creates a socket — domain AF_INET (IPv4), AF_INET6 (IPv6), AF_UNIX (local), AF_PACKET (raw Ethernet); type SOCK_STREAM (TCP, byte-stream, reliable) or SOCK_DGRAM (UDP, message-based, unreliable); returns a file descriptor. bind() associates a socket with a local address and port. listen() marks a socket as passive (server), with a backlog queue. accept() dequeues a connection from the completed handshake queue (returns a new fd). connect() initiates TCP three-way handshake (SYN, SYN-ACK, ACK). send()/recv(), read()/write() transfer data. TCP state machine: LISTEN ? SYN_RCVD ? ESTABLISHED ? FIN_WAIT_1/2 ? TIME_WAIT ? CLOSED (client side); LISTEN ? SYN_RCVD ? ESTABLISHED ? CLOSE_WAIT ? LAST_ACK ? CLOSED (server side). TIME_WAIT (2×MSL = 60-120 seconds) prevents delayed duplicate segments corrupting new connections — causes port exhaustion under high connection rates, mitigated by SO_REUSEADDR, SO_REUSEPORT, and tcp_tw_reuse.

TCP congestion control prevents senders from overwhelming the network. The congestion window (cwnd) limits the amount of unacknowledged data in flight (bytes in flight = min(cwnd, receiver_window)). Classic Reno: Slow Start phase (cwnd grows exponentially from 1 MSS by 1 per ACK until ssthresh or loss), Congestion Avoidance phase (linear growth: +1 MSS per RTT), on triple-duplicate ACK (fast retransmit, network congested but not severely): cwnd halved, fast recovery; on timeout (severe congestion): cwnd reset to 1 MSS. CUBIC (Linux default since 2.6.19): uses a cubic function of time since last loss event for cwnd growth — more aggressive recovery in high-bandwidth-delay-product networks, much better at filling 10Gbps+ links. BBR (Bottleneck Bandwidth and RTT, Google 2016): model-based — continuously estimates actual link bottleneck bandwidth and minimum RTT (rather than reacting to packet loss), sends at the estimated bottleneck rate with BBR-sized bursts — dramatically better throughput on high-BDP paths and paths with buferbloat, used by Google for all YouTube and Search traffic. QUIC (RFC 9000): UDP-based transport protocol, HTTP/3 carrier — per-stream flow control, 0-RTT reconnection, connection migration across IP changes, reduced head-of-line blocking.

At 100Gbps+ line rates, traditional kernel network stack becomes the bottleneck. DPDK (Data Plane Development Kit): user-space polling-mode drivers that completely bypass the kernel — NIC BAR (Base Address Register) is memory-mapped directly into a user-space process, huge pages allocated for packet buffers pinned in memory, CPU cores dedicated to packet processing in a tight poll loop. Achieves 80-200 million packets per second (Mpps) per core. Used in virtual switching (Open vSwitch DPDK), telecom NFV, firewalls, high-frequency trading market gateways. XDP (eXpress Data Path): attach eBPF programs to the NIC driver's receive path, before sk_buff allocation — packet is processed in the context of the NET_RX softirq with access to raw DMA buffer. Actions: XDP_PASS (continue to normal stack), XDP_DROP (discard, zero memory allocation — essential for DDoS mitigation at line rate), XDP_TX (reflect back from same interface), XDP_REDIRECT (send to another interface or AF_XDP socket). Cloudflare uses XDP to drop DDoS floods at 26 million packets/second without affecting legitimate traffic. RDMA: bypass kernel for remote memory access — covered in storage chapter.

Linux Netfilter framework: hooks at five points in the packet path (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) where kernel modules can inspect and modify packets. iptables (built on Netfilter): stateful packet filtering, NAT (masquerade for internet sharing, DNAT/SNAT for load balancing), mangle (packet modification) — tables/chains/rules model, O(N) rule matching — performance degrades with thousands of rules. nftables (successor to iptables): more expressive rule language, better performance through set-based matching, atomic rule updates, Linux 3.13+ used in recent RHEL/Ubuntu. ipvs (IP Virtual Server): layer-4 load balancing in kernel, used by kube-proxy in Kubernetes for Service routing (much faster than iptables for thousands of Services). eBPF-based networking: Cilium replaces kube-proxy entirely using eBPF programs attached to cgroup and TC hooks — O(1) service routing using eBPF hash maps instead of iptables rules, dramatically better performance at scale (Facebook reports 10x throughput improvement, Netflix uses Cilium at scale). tc (Traffic Control): ingress/egress packet queuing disciplines (qdiscs), traffic shaping, policing, classification — fq_codel and cake qdiscs provide active queue management combating bufferbloat.

When a computer powers on, the CPU begins executing code from a fixed physical address (0xFFFFFFF0 on x86 — reset vector) mapped to firmware ROM. Legacy BIOS (Basic Input/Output System): 16-bit real mode, 1MB addressable memory space, MBR-based boot (512-byte first disk sector containing 446 bytes of bootloader, 64-byte partition table, 2-byte signature 0x55AA), limited to 2TB disks with MBR partitioning, slow POST (Power-On Self Test). UEFI (Unified Extensible Firmware Interface, Intel EFI ? UEFI Forum 2005): full 32/64-bit operation, GPT (GUID Partition Table) supports 128 partitions and 9.4 ZB disks, EFI System Partition (ESP, FAT32 filesystem at /boot/efi) holds .efi bootloader files, UEFI drivers, and shell. Secure Boot (UEFI 2.3.1): firmware verifies each component's cryptographic signature against PK (Platform Key), KEK (Key Exchange Key), DB (allowed), and DBX (revoked) databases stored in NVRAM — prevents bootkit and rootkit persistence across reboots. Linux Secure Boot chain: UEFI ? shim (Microsoft-signed shim bootloader) ? GRUB (signed with distro key) ? Linux kernel vmlinuz (signed) ? integrity-protected kernel modules via PKCS#7 signatures.

GRUB2 (GRand Unified Bootloader version 2) is the most widely used Linux bootloader. Boot sequence with UEFI: UEFI firmware loads grubx64.efi from ESP ? GRUB reads /boot/grub/grub.cfg configuration file ? GRUB presents menu (configurable timeout) ? user selects entry (or default chosen) ? GRUB loads Linux kernel image (vmlinuz, a compressed self-extracting bzImage) and initramfs (initial RAM filesystem image) into memory ? passes kernel command-line parameters (root=UUID=..., ro, quiet, splash, net.ifnames=0, console=ttyS0,115200) ? jumps to kernel entry point. Key kernel parameters: root= (root filesystem device or UUID), ro (mount root read-only initially — systemd remounts rw), init=/path (override PID 1), nomodeset (disable kernel mode-setting for display debugging), single/rescue (single-user recovery mode), mem=N (limit memory for testing). systemd-boot (sd-boot): minimal UEFI-native bootloader — no legacy support, reads /boot/loader/loader.conf and entry files from /boot/loader/entries/*.conf — faster and simpler than GRUB for UEFI systems. Windows Boot Manager (bootmgfw.efi) manages Windows startup.

Kernel boot sequence after GRUB hands over control: compressed vmlinuz decompresses itself (GRUB loads head_64.S startup code ? calls decompress_kernel() ? kernel unpacks to its load address). Architecture-specific setup (arch/x86/boot/): set up GDT (Global Descriptor Table), IDT (Interrupt Descriptor Table), initial page tables for identity mapping, enable paging, switch to 64-bit long mode, call start_kernel(). start_kernel() (init/main.c — the main C entry point): boot_cpu_init() (mark boot CPU active), setup_arch() (parse ACPI/device tree, initialize memory maps from BIOS/UEFI memory map, set up NUMA topology), mm_init() (buddy allocator, slab allocator initialization), sched_init() (scheduler data structures, create idle process task 0), init_IRQ() (initialize interrupt controllers: PIC, APIC, IO-APIC), time_init() (hardware timer: HPET, TSC calibration), kernel_init() kthread (scheduled to start userspace). Mounts initramfs (cpio-format compressed archive embedded in or alongside vmlinuz) as rootfs ? runs /init (systemd in initramfs) which loads drivers (disk, LUKS, LVM, RAID, filesystem modules) ? pivots to real root filesystem ? exec() real /sbin/init (systemd, PID 1 in real root).

The Linux kernel (~35 million lines of code in 6.x, with drivers comprising ~55%) consists of interconnected subsystems: Memory Management (mm/) — buddy allocator (powers of 2 free block lists), SLAB/SLUB allocator (slab caches for frequently allocated objects like task_struct, sk_buff, inode), vmalloc (virtually contiguous but physically scattered), OOM killer (selects victim process when out of memory based on oom_score). Virtual File System (fs/) — VFS abstraction layer (superblock, inode, dentry, file objects with operation function pointers), concrete FS implementations (ext4, xfs, btrfs, tmpfs, procfs, sysfs, overlayfs). Network Stack (net/) — protocol implementations (TCP, UDP, IPv4/IPv6, ICMP, ARP), Netfilter/eBPF hooks, socket layer. Device Drivers (drivers/) — the largest subsystem; character, block, network, USB, PCIe, platform, power management drivers. Process Scheduler (kernel/sched/) — CFS, real-time schedulers, load balancer, scheduler topology. Security (security/) — Linux Security Module (LSM) hooks at security-sensitive kernel operations, SELinux/AppArmor/BPF-LSM implementations. The /proc and /sys virtual filesystems expose kernel internal state as readable/writable files — essential for system administration and performance monitoring.

systemd (Lennart Poettering, 2010; now universal across major Linux distributions) replaces traditional SysV init scripts with a dependency-based parallel service manager. Core concepts: Units (service .service, socket .socket, target .target, timer .timer, mount .mount, device .device, path .path — configuration files describing resources), Dependencies (After=, Requires=, Wants=, Conflicts= — systemd resolves the dependency graph and starts units in parallel where possible), Targets (replace SysV runlevels: multi-user.target ˜ runlevel 3, graphical.target ˜ runlevel 5, rescue.target ˜ runlevel 1). Boot performance: systemd activates sockets before services (socket activation) — services start lazily when first connection arrives, and all non-dependent services start in parallel ? typical desktop boot in 5-10 seconds. journald: structured binary logging daemon capturing stdout/stderr of all services, kernel messages, and audit log; queried with journalctl -u nginx --since today. cgroups integration: each service gets its own cgroup for resource accounting and limits (CPUQuota=50%, MemoryMax=512M in unit file). Container and VM management: systemd-nspawn (lightweight containers), systemd-machined (VM lifecycle).

eBPF (extended Berkeley Packet Filter) is arguably the most important Linux kernel innovation of the last decade — a mechanism to safely run sandboxed, verified programs directly in kernel space without requiring kernel module development or kernel source changes. eBPF programs are written in restricted C, compiled to eBPF bytecode, submitted to the kernel where the verifier statically proves: the program terminates (no loops without bounded iteration), all memory accesses are within bounds, no null pointer dereferences, no uninitialized reads, type safety in helper function calls. Verified programs are then JIT-compiled to native machine code. Programs attach to kernel hook points: kprobes (any kernel function entry/return), uprobes (user-space function tracing), tracepoints (stable kernel event hooks — sched:sched_switch, net:netif_receive_skb), XDP (network fast path), TC (traffic control), cgroup operations, socket filter, security hooks (BPF-LSM). Maps (hash tables, arrays, ring buffers, LRU maps) enable data sharing between eBPF programs and user space. Production uses: Cilium (container networking, Kubernetes), Falco (runtime security), Katran (Facebook L4 LB), Cloudflare DDoS mitigation, Meta's Shard Manager, Netflix CPU profiling.

The microkernel architecture is experiencing a renaissance driven by security-critical and formally-verified systems. seL4 (NICTA/Data61, 2009 verified, open-sourced 2014): the first OS kernel with complete formal verification — every line of C code mathematically proven correct with respect to its abstract specification using the Isabelle/HOL theorem prover, and the binary verified against the C code (compiler correctness). 8,700 lines of C, 600 lines of assembly, ~40 pages of formal proof obligations. Provides: capability-based access control (every resource access requires holding an appropriate capability token — no ambient authority), inter-process communication (IPC), memory management, scheduling — all other OS services in user space. Used in defense (US Air Force F-16 systems), medical devices, automotive ADAS (seL4-based hypervisor for running safety-critical and entertainment systems on same hardware). Google Fuchsia OS: new OS for IoT and potentially consumer devices — Zircon microkernel (capability-based security model, not POSIX-compatible), Starnix component provides Linux syscall compatibility. The Tanenbaum-Torvalds debate (1992 comp.os.minix): Tanenbaum advocated microkernels; Torvalds chose monolithic. Linux won the server/desktop/mobile market, but seL4 proves microkernels are essential for highest-assurance systems.

WebAssembly (WASM) began as a browser compilation target but is evolving into a universal portable execution environment. WASM properties enabling OS-like abstractions: memory-safe by design (no raw pointers, typed memory, bounds-checked — no buffer overflows at the WASM level), sandboxed by default (no I/O capabilities without explicit grants), portable bytecode (same binary on x86, ARM, RISC-V, WebAssembly everywhere), near-native performance (~80-90% of native via JIT/AOT compilation). WASI (WebAssembly System Interface, Bytecode Alliance): a modular, capability-based system interface standard — modules must be explicitly granted capabilities (wasi_filesystem::OpenDir for specific directory, wasi_sockets::UDPSocket) — unlike POSIX where root can access anything. Component Model: compose WASM modules from different languages (Rust, C, Python, Go) with type-safe interfaces. Runtimes: Wasmtime (Bytecode Alliance, Rust), WasmEdge (CNCF, embedded), wasmer. Use cases: Fastly Compute@Edge (sub-millisecond cold start), Cloudflare Workers (JavaScript + WASM), Fermyon Spin (WASM microservices), Docker + WASM (alternative to Linux containers — runs on Windows/Mac/Linux without a Linux VM), plugin systems (Extism for arbitrary language plugins).

Unikernels compile an application together with only the OS library components it needs into a single bootable image — no shell, no other processes, no unnecessary kernel subsystems. Result: minimal attack surface (no SSH daemon, no package manager, no unneeded syscalls), fast boot (10-50ms), small memory footprint, specialized for one workload. MirageOS (Cambridge University): OCaml-based, type-safe unikernel — entire OS stack (network stack, TLS library, filesystem) reimplemented in OCaml; used by Cloudflare for its DNS infrastructure, extremely reliable due to OCaml's type safety. Nanos (NanoVMs): runs existing Linux applications as unikernels without modification — Nanos provides enough Linux ABI compatibility (no recompilation needed), single process per VM, runs on KVM/Xen/AWS. OSv: JVM-optimized unikernel running Java/JVM applications directly on hypervisors — eliminates host OS overhead for JVM workloads. Rumpkernels: run NetBSD kernel components as user-space libraries on any OS (Rumprun unikernel). AWS Firecracker microVMs: not strictly unikernels but achieves similar density — stripped-down 5MB minimal Linux kernel, 4 virtio devices, boots in 150ms, 5MB footprint, powers AWS Lambda and Fargate. Linux io_uring + eBPF approaches are making traditional kernels more specialized and performant.

AI infrastructure demands are driving new OS developments. GPU scheduling: CUDA (NVIDIA), ROCm (AMD), and Metal (Apple) implement their own scheduling models separate from the CPU scheduler — the OS provides the hardware interface (NVIDIA kernel module, AMD AMDGPU), userspace drivers (CUDA runtime, Vulkan), and memory management for unified memory. Heterogeneous computing OS challenges: managing power between CPU efficiency/performance cores and GPU/NPU units, scheduling across ISA boundaries, NUMA-aware placement of model weights and activations in memory hierarchy. CXL (Compute Express Link, PCIe 5.0-based): enables memory pooling — multiple servers share a large pool of CXL-attached DRAM/PMEM, each accessing it with ~200ns latency. The OS must be CXL-aware for efficient placement. RISC-V OS ecosystem: Linux, FreeBSD, seL4, FreeRTOS all run on RISC-V — open ISA enabling custom hardware security extensions. Confidential computing: AMD SEV-SNP, Intel TDX (Trust Domain Extensions) provide hardware-encrypted VM memory invisible to hypervisor — each CVM (Confidential VM) has an attestation report signed by the CPU hardware proving what code is running. Operating systems in 2030 will be defined by: heterogeneous compute management, hardware-enforced memory safety (CHERI capability hardware), formally verified components, and eBPF-style safe extensibility at scale.