How to Learn More About the Linux Kernel from Your Own Machine

Learning to work with GNU/Linux generally entails learning to work with a desktop environment. Theme technology allows these desktop environments to mimic the interfaces of iOS, Microsoft Windows and OS X devices. This helps to minimize this as it were. Many people do go further and learn Unix command line administration with the Bash or tcsh shells. However, becoming knowledgeable of the internals of the Linux kernel can help you to better understand how different pieces of opcode interact with each other.

Some people would argue that it would be best to go several steps further and additionally learn how compilers transmute C code into machine instructors for a microprocessor. Assembly code advocates would then argue it’s best to learn ASM to truly grasp programming on the x86 and x86_64 platforms. Irrespective of these positions, basic Linux commands can provide a wealth of information on how the kernel sees your computer. Learning through a look but don’t touch paradigm is a great way to master the kernel itself. While the root account was used for the examples on this page, it’s highly recommended that you only ever view kernel-linked directories through a user account.

Method 1: The /proc Directory

The /proc directory sits in one of the primary regions of the top-level root directory in any Unix file structure. It contains what’s called the proc file system, better known as procfs that contains information about the way different resources access kernel memory. It’s mapped to /proc at the time the system boots. Since this proxy file structure serves as an interface to the internal data structure inside the Linux kernel, it’s once again best only to explore this via a user account. Most files get classified by the visible system file structure as read-only anyway, but it’s best to be on the safe side.

That being said, each of these is a text file, so you can view them if you wish. Use the cd command to enter the /proc directory, and then issue ls to get a look at what’s there. Use the cat, less or more command with any of the files to look at them. The cpuinfo file is a good place to start, since it displays how the kernel views your microprocessor. Look at the stat file for a view of running processes.


Typing cat devices will give you a look at what things are attached to your machine.


By the way, you can always issue the command man proc for a rundown of how the /proc file structure relates to the kernel. The page served comes from the Linux Programmer’s Manual.


Method 2: The /sys Directory

Your next stop on the tour of your kernel is /sys, which is another directory mapped to a pretend file structure. This follows the same general Unix concept as /proc does, but its instead actively exporting information about associated device drives and a number of kernel subsystems. If you’ve ever worked with a BSD-based system, then you might be more familiar with sysctl providing these functions. PCI, USB and S/390 bus devices are all mapped to the /sys directory.

Use cd /sys to head over to the directory and then issue the ls or dir command. You might have directories entitled block, class, devices, fs, kernel and maybe others. You can explore these for further flat files that contain information about the system, but once again do so from a user account and keep a look but don’t touch mentality about yourself.

Method 3: The /dev Directory

Use the cd /dev command to head over to the /dev directory, which might be the one kernel virtual structure you’re the most familiar with already. The name means devices, and contains file representation of devices attached to your system. An ls command in this directory will return many files on even the simplest server distribution.


A few of these are very special. The /dev/null file is a null device that does nothing. If you type cat /dev/null, then you’ll get nothing out of it. It’s called the bit bucket, and output can be redirected to it to keep the screen clean. A file called /dev/zero contains nothing but zero data, which can be written to a disk to zero it out. The random and urandom files contain random junk data for creating security hashes.

If you’ve ever formatted a disk, then you probably have at least some experience with the way that the Linux kernel views them. Each disk attached to the system gets a name like sda, sdb and so on for each disk. Different disk types get different names. Keep in mind that the /dev directory utilizes one potential formal computer science definition of disk rather than the way we’d usually use that term. This means a hard drive, an SSD, an SD Card, a microSDHC card, a mounted smartphone filesystem attached via USB, USB sticks and even mounted tablets are all disks to the kernel.

Each disk name in Linux then receives a numeral after it indicating a partition number. If you had an SSD with two primary partitions, then you might have /dev/sda1 and /dev/sda2 as valid volumes. More than likely if you’re running Linux from a desktop or laptop with MBR style partitioning, then you have /dev/sda1 set to the ext4 partition that actually has Linux installed on it. More than likely /dev/sda2 is an extended partition which then contains /dev/sda5 as a swap partition. This scheme is common, but by no means necessary. Note that since the swap partition in this common example is a logical disk inside of an extended partition, it receives 5 instead of 3 as its numeral.

Should you want to learn more about the way the kernel views and formats partitions, then you can actually view a supported partition list with the fdisk command. While fdisk doesn’t write partition tables until you tell it to, it’s still best to try this with something you don’t care about toasting. It’s recommended to point it at something like a blank USB stick you could just easily reformat.

Let’s say your stick is showing up as /dev/sdc, then you could use sudo fdisk /dev/sdc to get it loaded up. If you have a valid partition in it, then type t to change the type and the type L to load a hex code list. Note that MBR and GUID partition schemes talk to the kernel differently, and therefore have different assignments.


More often than not you’ll have drives set to type 83, which is for Linux drives, 82, which is for Linux swap partitions, or one of the FAT file types. FAT dates back in some form or another to 1977, and is still preferred for many types of mobile devices as well as many removable drives. Note that some partition types, such as type 0x0c, feature something called LBA support.

When a programmer designs a kernel for an operating system, they have a few different way they can look at disks. One is to divide the platters into cylinders, heads and sectors. This was the classic way to refer to hard drives for the longest time. Genuine disk geometry has never really been important to Linux, and this scheme unfortunately runs out of addresses after approximately 8 binary Gigabytes. The second way is to use Logical C/H/S addressing, which does this, but then allows the disk controller to map cylinder, head and sector numbers wherever they’d like. This is why an operating system could theoretically claim there were heads in an SD card or a USB stick when this is physically impossible.

The third method is through Logical Block Addressing, which is what LBA stands for. Each physical block in a volume receives a numeral in this scheme. The operating system tells the disk controller to write to a certain numbered block, but doesn’t actually know whether that’s the direct block on disk. This is the scheme most used today, and it’s certainly been used on the vast majority of hard disks since the mid-1990s.

Linux offers kernel support to mount a wide variety of partition types without direct input, but it’s still best not to be too outlandish when selecting them. You could toast your data if you made a very strange partition type to file system matching choice.

Method 4: System Calls from the Linux Programmer’s Manual

Onboard man pages readers included with a majority of Linux distributions can actually give you a crash course on system calls, which can help immensely with learning about the kernel. Start the xman graphical man pages browser either from a .desktop link if you have one, or alternatively by holding down the super key and R at the same time then typing xman and pushing enter. Select the “Manual Page” option and then choose “Sections” and finally “(2) System Calls” from the drop-down menu.


Once an option reading “intro” appears, select that. A page from the Linux Programmer’s Manual that will teach you quite a bit about system calls will then greet you.


Kevin Arrows
Kevin is a dynamic and self-motivated information technology professional, with a Thorough knowledge of all facets pertaining to network infrastructure design, implementation and administration. Superior record of delivering simultaneous large-scale mission critical projects on time and under budget.
Back to top button