At first glance, Linux sounds strange and unapproachable, like that one girl you know. She looks at you from the corner of her eye, but you being you, you never managed to gather enough courage to just go talk to her!
I’m sorry, but I unfortunately can’t help you with that particular quagmire. I can promise to make Linux more approachable for you through a chapter-by-chapter deep dive.
I will be using How Linux Works (3rd Edition) by Brian Ward. This book is not only updated to teach how modern Linux works, but also gives you a deep enough dive to understand all layers of abstraction.
Abstraction? Nothing fancy, to be honest. It’s just a word that means you can ignore most of the details that make up the component at hand and focus on what it does and how it works.
Simple example: to drive a car, you do not need to know how the engine works, you just need to know how to drive. But if you are a car mechanic, you must know engines in order to repair them, though you still don’t have to worry about the source of the iron used to make the engine in the first place. So basically, it’s abstraction on top of abstraction.
As for Linux systems, there are three main layers of abstraction.
Hardware layer - This is where all the physical components of your system live. For example, the CPU, keyboard, memory, etc.
Kernel layer - The heart of the Linux system. It is an interface between the user and hardware layers. The kernel is responsible for managing processes (a process is simply a running instance of a program), drivers, the CPU, etc.
User layer - This is where you and I live, along with the programs that we use. Each process running here has its own share of the computer’s hardware and is managed by the kernel.
Show Image
Main Memory and State
Before we go further, a quick word on main memory (RAM), since everything else depends on it. Think of it as a giant row of tiny switches, each one either 0 or 1. These are called bits. Everything your computer is working on right now lives in there, and the CPU reads and changes those bits all day long.
The exact arrangement of those bits at any given moment is called state. A running process is really just its state sitting in memory, nothing more mysterious than that. Keep this in mind, because it comes back later.
Kernel vs User Processes
User programs do not have unrestricted access to memory. What if someone using malicious software tried to modify important files your running program needed? To prevent this, user programs are given their own separate memory space in RAM, and the kernel sets the rules for what each process can touch.
User programs run in user mode and have restrictions, while the kernel runs in unrestricted kernel mode.
Understanding the Kernel
As previously mentioned, the kernel provides an abstraction between the user and the hardware. An OS is more than a kernel, but the kernel is one of its main components. There are many jobs the kernel must perform:
Processes - The kernel keeps track of which process is allowed to use the CPU.
Memory- The kernel needs to keep track of all memory: what is currently in use by a particular process, what might be shared between processes, and what is free.
Device drivers - The kernel acts as a medium between hardware and processes. It’s the kernel’s duty to operate the hardware.
System calls and support - System calls are the primary way for a process to communicate with the kernel.
Now we will briefly touch on each of these responsibilities.
Process Management
Process management means everything from the start to the termination of processes. To be precise: starting, pausing, resuming, scheduling, and terminating them.
On a modern operating system, we tend to see processes running “at the same time”. In reality, each process (talking strictly about a single-core CPU) runs one at a time, but switching from one process to another is so fast that it seems as if they are running simultaneously. Each process runs for a short while, then the kernel stores its state (CPU registers, memory, etc.), pulls in the next process, loads its data, and resumes it. This is known as context switching.
The kernel is responsible for context switching. To understand how it works, suppose a process has been running for its time slice and the time is now up. The kernel prepares to switch from that process to another one waiting to run:
The CPU interrupts the running process based on its internal timer and switches into kernel mode. This gives the kernel total control.
The kernel stores the current state of the process.
The kernel takes care of any pending work, like finishing up an I/O request the process had made.
The kernel analyzes the queue of waiting processes and picks one according to its scheduling policy.
The kernel loads the selected process and its data.
The kernel tells the CPU how long to run the process and switches the CPU to user mode, where the process takes control of the CPU.
Memory Management
Memory is a big deal. The kernel does the supreme job of managing memory, which is a complex task. The following conditions must hold:
The kernel must have a private area in memory that no process can access.
Each user process must also have its own private section in memory.
One user process may not access the private memory of another process.
User processes can share memory.
Some memory in user processes can be read-only.
The system can use more memory than its actual size by using disk space as an auxiliary.
Modern CPU architecture includes an MMU (Memory Management Unit) that helps with address translation. When a process tries to access memory, it does not use the real address. The requested address is a virtual address, which the MMU translates into the actual physical address. This prevents the process from accessing parts of physical memory that are not its own.
Device Drivers and Management
Device drivers are typically part of the kernel. They translate generic system calls like read(), open(), etc. into actual machine signals. They run in privileged kernel space, where they have access to raw hardware.
System Calls and Support
System calls allow a user process to do tasks that it cannot do on its own. Examples of system calls include read(), write(), open(), and fork().
A quick note: you might see malloc() mentioned alongside these, but it isn’t a system call itself. It’s a C library function that sits on top of system calls like brk() and mmap() to ask the kernel for memory.
To start a process, we need to understand two system calls in particular:
*fork() *- The process creates a 1:1 copy of itself. The copy inherits all the state of the parent process.
*exec() *- It comes in many forms, but essentially it replaces the current process with the one specified (exec(program)).
Other than init (PID 1, the very first process the kernel starts), every process is started by another process. When you type “ls” in the terminal, the following happens:
In plain words: your shell (the program you’re typing into) calls fork() to make a copy of itself. That copy, called the child, then calls exec(“ls”), which swaps it out for the ls program. Meanwhile, the original shell (the parent) just waits until ls is done, then hands you your prompt back.
User Space
User space is where all the real work happens, since each process is just a state in memory. User space refers to the entire collection of memory used by running processes.
From the kernel’s point of view, all programs running in user space are technically equal. Some processes make use of others for specific functions. The processes close to the user expose many features, but as we move away from the user, we get to processes that perform one task and do it well. For example, a program like vim exposes a full text editor with advanced features, while a program like grep (which is also very powerful) helps you find text in a file blazing fast.
Users
One last thing before we wrap up. Every process in Linux is owned by a user. That is how the kernel decides who is allowed to do what. A regular user can play around with their own files and processes, but not with anyone else’s.
Then there is root, also known as the superuser. Root can do anything, no questions asked, think of it as the master key to the whole system. Great power and all that, so be careful: one wrong command as root and you can break your entire system.
TL;DR
Linux has three layers of abstraction: hardware, kernel, and user.
A running process is just state (a pattern of bits) sitting in memory.
The kernel manages processes, memory, device drivers, and system calls.
Processes take turns on the CPU so fast it looks simultaneous. This is context switching.
The MMU translates virtual addresses to physical ones, keeping processes out of each other’s memory.
New processes are born through fork() (copy yourself) and exec() (become something else).
Every process belongs to a user, and root is the all-powerful one.
Conclusion
I hope you enjoyed my concise but complete overview of chapter 1 of “How Linux Works”. Please like and follow me so I can keep making educational content, improve myself, and provide you all with greater value.
Thank you very much for reading. I’ll see you in the next one!
Top comments (0)