Kernel and user space

The kernel controls access to hardware and shared resources. Programs normally run in user space with limited privileges.

This split exists for protection. If every program could write to the disk hardware directly, one buggy program could corrupt any file, read another program’s memory, or take the network down. Instead, the kernel is the only code with full control, and everything else — your shell, your editor, the web server — must go through it.

System calls: the controlled door

A system call is the controlled path a program uses to ask the kernel for work such as opening a file or creating a process.

When you run cat /etc/hostname, the cat program does not touch the disk. It asks the kernel to open the file, asks it to read the bytes, and asks it to write them to your terminal. Three requests, all answered by the kernel, all checked against permissions before anything happens.

Seeing both sides

The kernel itself shows up in a process listing as bracketed names:

ps -e | head -5
#     PID TTY          TIME CMD
#       1 ?        00:00:04 systemd
#       2 ?        00:00:00 kthreadd

systemd is the first user space process. Entries like kthreadd are kernel threads. Everything you will start on this machine joins the user space side of that list.

One detail that surprises people: even root runs in user space. Root is a powerful account, and the kernel grants its requests broadly, but a root shell still works through system calls like every other program. Root is not “inside” the kernel.

Why this boundary helps you

This boundary is one reason a broken application does not normally crash the entire operating system. When a program misbehaves — reads memory it does not own, for example — the kernel kills that one process and everything else keeps running.

That gives you a diagnostic rule. One application crashing repeatedly is a user space problem: look at that program, its configuration, its logs. The whole machine freezing or rebooting on its own points at the kernel, a driver, or hardware — a much rarer and more serious class of failure.