Every OS provides these subsystems, whatever its structure. PROCESS MANAGER create/terminate processes, schedule the CPU, handle context switches, IPC MEMORY MANAGER allocate and free memory, virtual address translation, paging, swapping FILE SYSTEM files, directories, permissions, allocation of disk blocks I/O SUBSYSTEM device drivers, buffering, caching, spooling SECONDARY STORAGE disk scheduling, free-space management NETWORKING protocol stacks, sockets PROTECTION/SECURITY user identity, permissions, isolation USER INTERFACE shell (CLI) and/or window system (GUI) TWO PARTS OF THE INTERFACE, and the distinction is examined: SYSTEM CALLS the programmatic interface to the kernel open(), fork(), read(), write(), exit() → the only legitimate way into kernel mode SHELL / GUI a program that runs in USER mode and issues system calls on your behalf → NOT part of the kernel. `ls` is an ordinary program; it just calls opendir/readdir. This is why you can replace bash with zsh without touching the OS, and why "the shell is not the operating system" is a standard exam correction.

1. MONOLITHIC (simple / no structure) the whole OS is one program in one address space; any part can call any other part directly. ✔ FAST — a subsystem call is a function call ✔ efficient sharing of data structures ✗ no isolation: one bad driver crashes the whole system ✗ hard to maintain as it grows ✗ any change means rebuilding and rebooting the kernel examples: early UNIX, MS-DOS, and (in the loose sense) Linux — though Linux is really MODULAR (see 4). 2. LAYERED the OS is divided into N layers; layer i may use only the services of layer i−1. layer N user interface ... layer 2 I/O management layer 1 CPU scheduling layer 0 hardware ✔ easy to debug and verify — build and test layer by layer, since each depends only on the layer below ✔ clean design discipline ✗ SLOW: a request may traverse many layers, each adding a call and a parameter copy ✗ deciding the layer order is genuinely hard — does the memory manager sit above or below the disk driver? Paging needs the disk; the disk driver needs memory for buffers. That circularity is why strict layering is rare. example: THE (Dijkstra, 1968) — the original, and largely an academic design. 3. MICROKERNEL keep only the essentials in the kernel; run everything else as user-mode SERVER processes communicating by message passing. IN the kernel: IPC, basic scheduling, minimal memory management, low-level hardware access OUT of the kernel: file system, device drivers, networking, display — all user processes ✔ RELIABLE — a crashed driver is a crashed user process; the kernel restarts it and the system survives ✔ SECURE — least privilege; a compromised driver has no kernel access ✔ extensible — add a service without touching the kernel ✗ SLOWER — every service request is now IPC (two context switches and message copying) instead of a function call ✗ more complex to design examples: Mach, MINIX 3, QNX, seL4, L4, Hurd 4. MODULAR (loadable kernel modules) — the practical answer a monolithic kernel that can load and unload components at RUN TIME. ✔ the speed of monolithic (modules run in kernel space and call directly) ✔ much of the flexibility of a microkernel (load a driver without rebooting) ✗ still no isolation — a buggy module can still panic the kernel examples: Linux (.ko modules), Solaris, modern Windows, FreeBSD 5. HYBRID a microkernel core with substantial subsystems in kernel space for performance. examples: Windows NT family, macOS/iOS (XNU = Mach + BSD) In practice: MODULAR and HYBRID are what ships. Pure monolithic and pure microkernel are the endpoints of a spectrum used to explain the trade-off.

/* Verified on Darwin 25.5.0 arm64.
   Every line marked ← is a transition into KERNEL MODE. */
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>

int main(void) {
    int fd = open("/tmp/sc_test.txt",
                  O_CREAT|O_WRONLY|O_TRUNC, 0644);   /* ← syscall */
    if (fd < 0) { perror("open"); return 1; }

    const char *msg = "system calls are the OS interface\n";
    write(fd, msg, 34);                              /* ← syscall */
    close(fd);                                       /* ← syscall */

    struct stat st;
    stat("/tmp/sc_test.txt", &st);                    /* ← syscall */
    printf("wrote %lld bytes; inode=%llu links=%u\n",
           (long long)st.st_size,
           (unsigned long long)st.st_ino, st.st_nlink);
    printf("my pid=%d  parent pid=%d  uid=%d\n",
           getpid(), getppid(), getuid());            /* ← 3 syscalls */
    return 0;
}
MEASURED OUTPUT:
wrote 34 bytes via open/write/close; inode=10936246 links=1
my pid=74921  parent pid=74911  uid=501

THE SIX CATEGORIES OF SYSTEM CALL, with real examples: PROCESS CONTROL fork, exec, exit, wait, kill FILE MANAGEMENT open, read, write, close, lseek, stat DEVICE MANAGEMENT ioctl, read, write (devices are files) INFORMATION getpid, getppid, time, sysctl COMMUNICATION pipe, socket, send, recv, shmget PROTECTION chmod, chown, umask, setuid WHAT ACTUALLY HAPPENS ON A SYSTEM CALL: 1. the library wrapper puts the call number in a register 2. it executes a trap instruction (svc on ARM64, syscall on x86-64) 3. the CPU switches to KERNEL MODE and jumps to a fixed handler address 4. the kernel validates the arguments — it must NEVER trust a user pointer 5. the kernel performs the operation 6. it returns the result and switches back to USER MODE Step 4 is where security lives. Every pointer a user process passes must be checked against that process's address space, or a malicious program could make the kernel read or write anywhere. WHY THE COST MATTERS: a system call is roughly 100× a function call, because of the mode switch and validation. That is why: · stdio buffers writes rather than calling write() per byte · high-performance servers use io_uring or epoll to batch calls · the inode number above came from ONE stat() call rather than several queries