The Two Paths — Git Clone vs Tarball

In the previous lecture we saw how to download a kernel tarball. Now we look at two complete paths to get the kernel source onto your machine and ready to build. The path you choose depends on what you plan to do with the kernel.

1. Cloning the Linux Kernel via Git

When you run git clone on the kernel repository, you are not just downloading the source files. You are downloading the entire history of every change ever made to Linux — decades of commits from thousands of developers worldwide.

There are multiple Git trees in the Linux kernel ecosystem. Understanding the hierarchy helps you pick the right one:

Cloning the Mainline Kernel Tree

The mainline tree is Linus Torvalds’ personal tree. All official kernel releases originate here. For anyone learning Linux kernel programming or Linux device driver development, this is the right Git tree to clone:

# Clone the full mainline Linux kernel tree
# WARNING: This downloads several gigabytes of data
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

2. The Right Way — Shallow Clone

For learning kernel programming, you do not need 30 years of commit history. You just need the latest code. A shallow clone lets you download only the most recent commits instead of the entire history. This saves enormous amounts of time and disk space.

Here is how to do a shallow clone with only the last 3 commits of history:

# Shallow clone — downloads only the 3 most recent commits
# This is the recommended approach for students and developers
git clone --depth=3 \
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

3. What Is linux-next and Should You Use It?

You will hear linux-next mentioned often in kernel development discussions. Here is the plain explanation of what it is and who actually needs it.

The Linux kernel development cycle works like this: Linus Torvalds opens a merge window for about two weeks, during which subsystem maintainers submit their patches. Before those patches land in Linus’s mainline tree, they all get merged into linux-next — a tree that acts as the kernel’s pre-integration test environment. It is rebuilt and updated every day.

Because linux-next pulls in patches from dozens of subsystems simultaneously, it is inherently unstable. It may fail to compile, fail to boot, or behave unpredictably on any given day. It exists purely as a testing ground, not as a usable kernel.

4. Extracting the Kernel Source Tarball

If you followed Path A from the previous lecture and downloaded a .tar.xz tarball, you now need to extract it. The tar command handles this.

Simple Extraction — Into the Current Directory

# Extracts into a folder named linux-6.12/ inside ~/Downloads/
tar xf ~/Downloads/linux-6.12.tar.xz

You do not need to add -J for xz or -z for gzip. Modern tar automatically detects the compression format from the file header, so tar xf works universally regardless of compression type.

Better Practice — Extract Into a Dedicated Kernels Folder

Scattering kernel source directories inside ~/Downloads gets messy fast. The cleaner approach is to keep all your kernel sources in a dedicated directory:

# Step 1: Create a dedicated kernels folder
mkdir -p ~/kernels

# Step 2: Extract the tarball directly into it
tar xf ~/Downloads/linux-6.12.tar.xz --directory=${HOME}/kernels/

# Your kernel source is now at: ~/kernels/linux-6.12/

The --directory flag tells tar to place all extracted files inside that target folder instead of the current working directory. The -p flag in mkdir means: create parent directories as needed, and do not fail if the folder already exists.

5. Setting the KDIR Environment Variable

This is one small habit that pays off constantly in kernel development. The path to your kernel source tree appears in dozens of places — build commands, Makefiles, grep searches, and cross-compilation setups. Instead of typing the full path every time, set it once as an environment variable:

# Point KDIR at your kernel source tree
export KDIR=${HOME}/kernels/linux-6.12

# Verify it was set correctly
echo $KDIR
# Expected output: /home/yourname/kernels/linux-6.12

# Confirm the source is there
ls $KDIR
# Should show: Makefile  arch  block  certs  crypto  drivers  fs  ...

# Now use it in build commands like:
make -C $KDIR M=$(pwd) modules

# For bash users:
echo 'export KDIR=${HOME}/kernels/linux-6.12' >> ~/.bashrc
source ~/.bashrc

# For zsh users:
echo 'export KDIR=${HOME}/kernels/linux-6.12' >> ~/.zshrc
source ~/.zshrc

6. Recommended Directory Layout for Kernel Development

When you work with multiple kernel versions over time — and in embedded development you almost always do — having a consistent folder structure prevents confusion and mistakes.

~/kernels/
├── linux-6.12/          LTS kernel — for production or embedded work
├── linux-6.18/          Newer LTS kernel — for testing newer APIs
├── linux-7.0/           Latest stable — for learning new features
├── linux/               Git clone of mainline (kept updated with git pull)
│
~/kernel-modules/        Your own kernel module source code goes here
~/kernel-builds/         Out-of-tree build output goes here

The key principle is to keep your own code inside kernel-modules/, completely separate from the kernel source inside kernels/. You should never modify files inside the kernel source tree when you are just writing a module — the kernel source should remain a clean, unmodified reference.

7. Why You Should Not Use /usr/src/ Anymore

If you read older Linux kernel books or tutorials from the 2000s, they tell you to put the kernel source inside /usr/src/linux/. This practice is outdated and you should avoid it.

The core reason for the change is simple: you should not need root privileges just to read or compile kernel source code. When everything lives inside your home directory, you have full read-write access without sudo, you can maintain multiple kernel versions side by side without conflict, and an accidental rm -rf only affects your home directory, not critical system paths.

8. Complete Workflow — From Zero to Kernel Source Ready

Here is the full sequence for both paths, from an empty terminal to a kernel source tree ready to configure and build:

## PATH A: Tarball Workflow ##

# 1. Download kernel 6.12 LTS (update version as newer LTS releases)
wget --https-only \
     -O ~/Downloads/linux-6.12.tar.xz \
     https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.12.tar.xz

# 2. Create kernels directory
mkdir -p ~/kernels

# 3. Extract into it
tar xf ~/Downloads/linux-6.12.tar.xz --directory=${HOME}/kernels/

# 4. Set environment variable
export KDIR=${HOME}/kernels/linux-6.12

# 5. Verify — you should see Makefile, arch/, drivers/, etc.
ls $KDIR


## PATH B: Git Clone Workflow ##

# 1. Go to your kernels directory
mkdir -p ~/kernels && cd ~/kernels

# 2. Shallow clone — much faster than a full clone
git clone --depth=3 \
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

# 3. Set environment variable
export KDIR=${HOME}/kernels/linux

# 4. Verify
ls $KDIR