Building the Linux Kernel from Source

📘 Linux Kernel Programming -Building the Linux Kernel from Source

◀ Ch1: Workspace Setup
Part 1 of 3
Next Lec ▶

Linux Kernel Programming · Chapter 2

Building the Linux Kernel from Source

Part 1 — What we are building, how Linux versions work, and how the kernel development community actually operates.

3
Parts in Chapter 2
Beginner
Friendly Level
~20 min
Read Time

🎯 What You Will Learn in This Part

  • Why building the kernel from source is a valuable skill
  • The three components every Linux system must have
  • How to read and interpret a Linux kernel version number
  • How the Linux kernel development process actually works
  • The different types of kernel source trees you will encounter

1. Why Would You Build the Kernel from Source?

When you install Ubuntu or any Linux distro, it comes with a pre-built kernel. That is convenient — but it also means you are running what someone else decided is a “good enough for everyone” kernel. In embedded systems and kernel development, that is rarely acceptable.

Building the kernel yourself gives you complete control — you decide which features are compiled in, which drivers are included, what is optimised for your hardware, and what is left out entirely. This is not just a learning exercise; it is the real workflow that embedded engineers and kernel contributors follow every day.

💡 Think of it this way:

A pre-built distro kernel is like a readymade pizza — convenient but someone else chose the toppings. Building from source is like cooking your own — you pick every ingredient for your specific taste and hardware.

This chapter (split across three parts) walks you through the complete process step by step: downloading the source, understanding the layout, configuring what you want, and finally compiling and installing. For now, we lay the foundation.

2. Three Things Every Linux System Must Have

Before we dive into building the kernel, let’s take a step back and understand what actually makes a Linux system boot and run. Whether it is a massive data-center server, your laptop, or a tiny IoT sensor — every Linux system has exactly three mandatory components:

Every Linux System — Required Components
🥾
Bootloader
Runs first when you power on. Its job is to load the OS kernel into memory. Example: GRUB on x86 machines.
⚙️
OS Kernel
The Linux kernel itself. Manages hardware, memory, processes, and all system resources. This is what we are building.
📁
Root Filesystem
The filesystem containing all user-space programs, libraries, config files — everything above the kernel layer.
Power ON → Bootloader → Kernel → Root FS → System Ready

In this chapter, our entire focus is the middle piece — the kernel. We will not dig into the root filesystem internals here. For the bootloader, we will only touch GRUB configuration briefly and only on x86 machines, since that is the most common development setup.

📌 Good to Know:

On embedded systems, the bootloader is often U-Boot instead of GRUB, and the root filesystem might be a minimal BusyBox image or Buildroot-generated filesystem. The concept is the same — three layers, always.

3. Understanding Linux Kernel Version Numbers

Every Linux kernel release has a version number. You have probably seen strings like 6.8.0-45-generic or 6.6.30 and wondered what each part means. Let’s break it down properly.

On any Linux machine, run this command to see your current kernel version:

$ uname -r
6.8.0-45-generic

The format follows this pattern:

major.minor[.patchlevel][-EXTRAVERSION]

Also written as:  w.x[.y][-z]

Anatomy of a Kernel Version Number

6
.
8
.
0
45-generic

Part Symbol Example What It Means
Major w 6 The main kernel series. Changes very rarely — only when there is a truly significant architectural shift.
Minor x 8 Increments with every regular release cycle (roughly every 2-3 months). This is the number you see change most often.
Patchlevel y 0 Optional. Applied to stable kernels for critical bug or security fixes between regular releases. A kernel like 6.8.3 has patchlevel 3.
EXTRAVERSION -z -45-generic Optional. Also called localversion. Used by distributions to track their own internal changes, patch sets, or flavours.

Decoding a Real Version Number

Let’s decode 6.8.0-45-generic step by step:

6 → Major version (kernel series 6.x)
8 → Minor version (8th release in the 6.x series)
0 → Patchlevel (no stable patch applied yet)
-45-generic → Ubuntu’s internal build number and flavour

⚠️ Important Note:

Distribution kernels (Ubuntu, Fedora, RHEL, etc.) may not follow this convention strictly — they often add their own version suffixes and backported patches. Only vanilla kernels from kernel.org are guaranteed to follow this format cleanly. When we build our own kernel, we use the vanilla source.

📖 Historical Trivia:

In kernels older than 2.6, the minor number had a special meaning — an even number meant a stable release and an odd number meant a development/beta release. That convention no longer exists. Don’t let old documentation confuse you on this.

Where Does the Vanilla Kernel Come From?

The official Linux kernel source is published and maintained at kernel.org. The Linux Foundation — a non-profit organisation — stewards the kernel project and keeps the repository publicly available at no cost. This is where we will download our source code in the next part.

✅ Key Terms to Remember:

  • Vanilla kernel — the pure, unmodified kernel source from kernel.org. No distro patches.
  • Distribution kernel — a vendor-modified kernel (e.g., Ubuntu’s kernel with custom patches and security backports).
  • Stable kernel — a vanilla kernel branch receiving only critical fixes, suitable for production use.

4. How the Linux Kernel Development Process Works

Many people assume the Linux kernel is developed chaotically — thousands of random contributors pushing code without any structure. That is actually far from the truth. The Linux kernel has one of the most disciplined and well-documented development processes in all of open-source software.

Here is a simplified view of how the release cycle works:

Kernel Release Cycle (Simplified)
Merge Window
~2 weeks
Linus opens the tree for new features. Maintainers from subsystems (networking, drivers, filesystems, etc.) send their pull requests. This is where new code enters.
RC Phase
rc1 → rc7 (~6-8 weeks)
After merge window closes, Linus releases rc1 (Release Candidate). Only bug fixes allowed. Community tests heavily. rc2, rc3… up to rc7 or rc8 may be released until it is stable enough.
Final Release
e.g., v6.9
Linus tags the final release. A new stable branch opens for this version (e.g., linux-6.9.y) maintained by the stable team for security and critical fixes.
Total cycle: ~9-10 weeks per release. A new kernel version releases roughly every 2-3 months.

Types of Kernel Source Trees

When you visit kernel.org or explore kernel development, you will encounter different types of kernel trees. Understanding which one to use and when is important:

🔵 Mainline Tree
Maintained directly by Linus Torvalds. This is where all new development happens. The latest RC kernels and the final tagged releases come from here. Best for: cutting-edge development and testing.
🟢 Stable Tree
After a mainline release, a stable branch opens (e.g., linux-6.8.y). The stable team applies only bug fixes and security patches — no new features. Best for: production systems and distros that need reliability.
🟡 LTS (Long Term Support) Tree
Certain stable releases are designated LTS and maintained for 2-6 years instead of just a few months. Examples: 6.6 LTS, 5.15 LTS. Best for: Android, embedded products, enterprise — anywhere you need long-term stability without major version changes.
🟣 Subsystem Trees
Individual kernel subsystems (networking, USB, ARM, RISC-V, etc.) have their own trees maintained by subsystem maintainers. These feed into the mainline tree during each merge window. You will encounter these when contributing to specific areas.

🎯 For This Series:

We will download and build a stable vanilla kernel from kernel.org. This gives us a clean, known-good codebase without any distro-specific noise. Perfect for learning the build process and kernel internals.

5. The Build Steps — A Quick Preview

Now that you understand the context, here is a bird’s-eye view of the complete kernel build process we will follow across all three parts of this chapter:

Kernel Build Road Map
Step What Happens Covered In
1. Obtain Source Download the kernel tarball from kernel.org Part 2
2. Extract Unpack the tarball and explore the source tree layout Part 2
3. Configure Run menuconfig and select what to build in or out Part 2
4. Compile Run make to build the kernel image and modules Part 3
5. Install Install modules and kernel, update GRUB, reboot Part 3

🔑 Quick Summary — What We Covered

  • Building the kernel from source gives you full control over what runs on your system
  • Every Linux system needs exactly three components: bootloader, kernel, root filesystem
  • The kernel version format is major.minor[.patchlevel][-EXTRAVERSION]
  • The minor number increments with each release; EXTRAVERSION is distro-specific
  • The kernel has a well-defined release cycle: merge window → RC phase → stable release
  • For learning, always use the vanilla stable kernel from kernel.org

🎤 Interview Questions & Answers

Q1. What are the three mandatory components of any Linux system?

Every Linux system — from a supercomputer to a small IoT device — requires:

  • Bootloader — loads the kernel into memory at power-on (e.g., GRUB on x86, U-Boot on embedded).
  • OS Kernel — manages all hardware resources, memory, and processes.
  • Root Filesystem — contains all user-space programs, libraries, and configuration.

All three are required; the system cannot function if any one is missing or broken.

Q2. What does the output “6.8.0-45-generic” from uname -r tell you?

Breaking it down:

  • 6 → Major version (kernel series)
  • 8 → Minor version (8th release in the 6.x series)
  • 0 → Patchlevel (no stable patches applied yet)
  • -45-generic → EXTRAVERSION; this is Ubuntu’s internal build tag and flavour name, not part of the vanilla kernel versioning

This is a distribution kernel. A vanilla kernel would look like 6.8.3.

Q3. What is a vanilla kernel and why would you use it over a distro kernel?

A vanilla kernel is the original, unmodified kernel source released by Linus Torvalds at kernel.org. It contains no distribution-specific patches, backports, or custom configurations.

You use it when: you want to study the kernel exactly as the community develops it, when you need to reproduce issues without distro-specific changes interfering, or when you are developing kernel modules or patches that need to be submitted upstream.

Q4. What is an LTS kernel and who typically uses it?

An LTS (Long Term Support) kernel is a stable release that the kernel community commits to maintaining for 2 to 6 years, compared to just a few months for regular stable kernels. The LTS kernel receives security fixes and critical bug fixes over its extended lifetime.

Who uses it: Android (virtually every Android version is based on an LTS kernel), embedded product manufacturers who cannot afford frequent kernel upgrades, and enterprise Linux distributions like RHEL or Ubuntu LTS.

Q5. Explain the Linux kernel release cycle briefly.

The cycle has two main phases:

  • Merge Window (~2 weeks): After a release, Linus opens the tree. Subsystem maintainers send pull requests with new features and drivers. Only this window accepts new features.
  • RC Phase (~6-8 weeks): Merge window closes, rc1 is tagged. Only bug fixes are accepted. Multiple RC releases follow until the code is stable. Then Linus tags the final release.

The entire cycle takes about 9-10 weeks, producing a new kernel roughly every 2-3 months.

Q6. Why did older kernels use odd/even minor numbers — and does that still apply?
In kernels before version 2.6, an even minor number indicated a stable release (e.g., 2.4.x) and an odd minor number indicated a development or beta release (e.g., 2.5.x). This convention was dropped starting with the 2.6 series. Since then, the minor number simply increments with each release cycle, regardless of stability. Modern kernels from 4.x onward have no odd/even meaning at all.

Chapter 2 · Linux Kernel Programming
Part 1: Intro & Version Numbering ✅

Leave a Reply

Your email address will not be published. Required fields are marked *