The architecture of the Linux operating system is layered, consisting of multiple components.
At the base of it all, is the hardware, which consists of all the physical devices connected
to the system, such as hard drives, RAM, the CPU and so on.
Then the system has two spaces: the kernel space and the user space.
The kernel is the core component of the operating system.
Without the kernel there is no OS.
It manages the system’s resources, communicates with the hardware, and is responsible for
memory, processes, and file management.
You can think of the kernel as a busy assistant and a gate keeper for hardware.
Essentially, the kernel takes input from the user space and then directly interacts with
the hardware to perform some function.
The kernel has to manage processes kicked off by the users and programs, track where
things are stored, and determine which processes get access to various pieces of the hardware
at any given time.
And actually if implemented properly, the kernel is invisible to the user, basically
working in its own little world known as kernel space.
While what we see, as users—things like applications, databases, and files—are all
contained within the user space.
In fact, the kernel space and user space, are two separate areas within virtual memory.
Keeping these spaces separate helps keep the system more stable.
It prevents user applications from directly accessing the hardware.
Which means that if a process fails in user space, the damage is limited and can often
be recovered by the kernel.
But if these spaces are separate, how do we, as users, interact with the kernel and underlying
hardware?
The answer is the shell.
When you type commands into the terminal, you’re using the shell to perform actions
and call on the kernel.
There are many different shells you can use, but their core functionality is the same.
They give us a way to provide input to the kernel and ultimately the underlying hardware
of the system.
But the shell isn’t the only way to interact with the kernel.
We can also use applications, such as the desktop GUI or other software programs.
And if we drill down further, when we use these applications or the shell, we’re actually
having the user space interact with the kernel space through system calls.
Say a program needs to access a file stored on one of the hard drives.
It’ll make a request to the kernel so that it can open the file on the hardware device.
This request is done with a system call.
Some common system calls are open, read, write, close, exit.
In fact, most modern Linux operating systems have over 300 system calls.
However, in general, you probably don’t need to worry about knowing what these system
calls are or understanding the details of how they work.
That’s because the programs we use within the user space are taking our commands, then
using system libraries, such as the GNU C Library, to translate them into system calls
that the kernel runs.
All of which is done behind the scenes.
Which means the shell or GUI application is simplifying a lot of the complexity of interacting
with the kernel.
So in most cases, we as everyday users, don’t even need to think about the kernel being
there or worry about system libraries.
Now that we know the kernel is such a core component of the operating system, let’s
jump into a terminal to find out a little bit about the kernel that’s running on our
system.
If we use the command uname –r, it shows the name of the current kernel.
And despite it looking cryptic, there is some info we can gain from this.
The first digit is the kernel version, then major release, and these next digits go into
even finer detail about the release level.
Then el8 tells us it’s Oracle Linux 8.
If it was el7 it would be Oracle Linux 7.
And uek tells us this is the Unbreakable Enterprise Kernel.
If it was just el8, it would be the standard Red Hat Compatible Kernel.
And the architecture is x86_64.
Knowing these details about the kernel might be important for compatibility.
You might have a program that only works with a particular level.
Even though this is the kernel running currently, there may be multiple kernels available on
the system.
To take a look, we can use sudo ls –l /boot/vmlinuz*
And we see the kernel that’s currently running as well as two others.
By default, Oracle Linux boots with the most recent kernel and usually this is what we
want.
But, like I mentioned, there may be times for compatibility, that you’d need to use
another kernel.
We can change the default kernel that the boot loader uses when we're starting up the
system, by using the command sudo grubby --set-default /boot/vmlinuz and the kernel version.
This takes effect immediately and the setting persists across reboots, but to load the new
kernel we’ll have to reboot the system.
Here on the boot screen, we see that the kernel version I just configured is highlighted.
Now in the terminal, let’s run uname –r, and we see it shows the kernel we're now running
is the one that we just set as the default.
I think that's it for a quick overview of Linux architecture and the kernel.
To learn more about the features of Linux, check out the other introductory videos in
this series.
Thanks for watching.