A
AiTechWorlds
AiTechWorlds
Picture a packed concert. General admission fans can enjoy the show from the floor — great experience, but there are boundaries. The backstage area is off-limits: it holds expensive equipment, private dressing rooms, and the stage rigging. You need an authorized VIP pass to cross that line, and even then a security guard checks your credentials and escorts you.
Programs on your computer are like those general admission fans. They run in user mode — they can do a lot, but they cannot directly touch the hardware. The hardware is backstage. To get anything done at the hardware level — read a file, send a network packet, allocate more memory — a program must present its credential: a system call. The kernel is the security guard who checks it, performs the privileged action, and returns the result.
If any program could directly control the CPU, RAM, and disks, a single buggy application could corrupt the entire system. The hardware-enforced boundary between user mode and kernel mode is the single most important protection mechanism in a modern OS.
"The dual-mode operation provides us with the means for protecting the operating system from errant users — and protecting users from one another." — Silberschatz, Operating System Concepts
The CPU itself implements this boundary at the hardware level using a mode bit in a status register.
Mode Bit = 1 → User Mode (restricted instructions)
Mode Bit = 0 → Kernel Mode (all instructions allowed)
| Feature | User Mode | Kernel Mode |
|---|---|---|
| Can access all RAM | No | Yes |
| Can execute privileged CPU instructions | No | Yes |
| Can configure hardware directly | No | Yes |
| Who runs here | Applications, shell, Python scripts | OS kernel, device drivers |
| What happens on violation | Process is killed (segfault/SIGSEGV) | System crash (kernel panic) |
On x86 processors, there are four privilege rings (0–3). Linux and Windows use only Ring 0 (kernel) and Ring 3 (user) in practice.
The kernel is the portion of the OS that runs continuously in kernel mode. It is the first thing loaded at boot and the last thing running at shutdown. Everything else — your file manager, terminal, browser — runs on top of it.
Core responsibilities of the kernel:
A system call is a programmatic request to the kernel to perform a privileged operation. From the programmer's perspective, they look like ordinary function calls. Under the hood, they trigger a CPU trap instruction that switches the mode bit to 0, jumps to a kernel handler, and switches back when done.
User Program
|
| write(fd, buffer, n) <- C library wrapper
|
v
C Library (glibc)
|
| SYSCALL instruction <- hardware trap
|
v
Kernel (mode bit = 0)
|
| sys_write() handler runs
| data written to file
|
v
Return to user mode (mode bit = 1)
|
v
User Program continues
| Category | System Call | What It Does |
|---|---|---|
| Process | fork() | Create a copy of the current process |
| Process | exec() | Replace process image with a new program |
| Process | exit() | Terminate the current process |
| Process | wait() | Wait for a child process to finish |
| File I/O | open() | Open a file, return a file descriptor |
| File I/O | read() | Read bytes from a file descriptor |
| File I/O | write() | Write bytes to a file descriptor |
| File I/O | close() | Release a file descriptor |
| Memory | mmap() | Map a file or device into memory |
| Memory | brk() | Extend the heap |
| Network | socket() | Create a network socket |
| Network | connect() | Connect to a remote host |
| Info | getpid() | Get current process ID |
straceOn Linux, strace intercepts and logs every system call a process makes. It is one of the most powerful debugging tools available.
# Trace all system calls made by ls
strace ls /tmp
# Trace only file-related calls
strace -e trace=file ls /tmp
# Count system calls made by a program
strace -c python3 hello.py
Sample output:
execve("/usr/bin/ls", ["ls", "/tmp"], ...) = 0
openat(AT_FDCWD, "/tmp", O_RDONLY|O_DIRECTORY) = 3
getdents64(3, ..., 32768) = 128
write(1, "file1.txt file2.log\n", 21) = 21
close(3) = 0
exit_group(0) = ?
Every line is one system call — the kernel's name, arguments, and return value. On macOS, the equivalent tool is dtruss (uses DTrace).
A hardware interrupt is a signal from a device (keyboard, timer, NIC) that tells the CPU: "Stop what you're doing — I need attention." The CPU suspends the current process, saves its state, and jumps to the kernel's interrupt handler.
NIC receives a packet
|
v
CPU receives hardware interrupt signal
|
v
CPU saves current process state (registers, PC)
|
v
Kernel interrupt handler runs (kernel mode)
|
v
Packet copied to buffer, process notified
|
v
CPU restores saved state, resumes process
Software interrupts (also called traps or exceptions) occur when a program executes a system call instruction or causes a fault (divide by zero, page fault).
The Interrupt Descriptor Table (IDT) on x86 maps each interrupt number to its handler routine inside the kernel.
Not all kernels are built the same way. The architecture determines what lives in kernel mode and what doesn't.
The entire OS — file systems, device drivers, scheduler, memory manager — runs as one large program in kernel mode.
+--------------------------------------------+
| Kernel Mode |
| Scheduler | MemMgr | FS | Drivers | Net |
+--------------------------------------------+
Only the absolute minimum runs in kernel mode: scheduling, basic IPC, and memory management. Everything else (file systems, drivers) runs as user-space servers.
+--------------------+
| Kernel Mode |
| Sched | IPC | Mem |
+--------------------+
| User Mode Servers |
| FS | Drivers | Net|
+--------------------+
A pragmatic blend — critical drivers and subsystems stay in kernel mode for performance, while the design borrows modularity ideas from microkernels.
| Kernel Type | Examples | Speed | Stability |
|---|---|---|---|
| Monolithic | Linux | Fast | Driver crash = kernel crash |
| Microkernel | Mach, QNX | Slower (IPC overhead) | Very stable |
| Hybrid | Windows, macOS | Fast | Good |
open("data.txt", "r") in Python, Python's runtime calls the C library fopen(), which calls the openat() system call, which the Linux kernel executes on your behalf.CreateFile, ReadFile) ultimately maps down to NT kernel system calls (NtCreateFile, NtReadFile) via the ntdll.dll layer.dtrace and instruments let you profile system call overhead — a common technique for diagnosing slow disk I/O.strace on Linux lets you observe every system call a process makes in real time.Get this course's notes on Telegram!
Free cheat sheets, summaries & practice exercises