# Kernel Source Masterclass: Den Quellcode beherrschen

TL;DR / Management Summary Wer den Kernel selbst kompilieren oder verstehen will (Artikel 237), muss wissen, woher er den Quellcode bekommt und wie dieser aufgebaut ist. Wir nutzen das offizielle kernel.org Repository und lernen die Giganten der Verzeichnisstruktur kennen: arch/, drivers/ und fs/. Ein Senior Admin weiß, wo er Patches einspielt und wie er den Speicherplatz für den massiven Build-Prozess (oft > 20GB) plant.

# 1. Einführung: Bezugsquellen

Mainline vs. Distro.

Es gibt nicht “den einen” Kernel. Wir unterscheiden:

1. Mainline (Linus Torvalds): Das “Original” von kernel.org.
2. Stable / LTS: Für den produktiven Einsatz.
3. Distro Sources: Die Versionen von Red Hat, SUSE oder Arch mit spezifischen Patches.

# Quellcode laden (Git)

# Klone den Mainline-Stable-Zweig
git clone --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

# 2. Die Anatomie des Quellcodes

Was liegt wo?

Der Linux-Kernel besteht aus Millionen Zeilen C-Code. Die Struktur ist streng hierarchisch.

# 3. Die Build-Umgebung vorbereiten

Das Werkzeug bereitstellen.

Ein Kernel-Build braucht hunderte Libraries und Tools.

# Unter Arch Linux

sudo pacman -S base-devel xmlto kmod inetutils bc libelf elfutils python-sphinx python-sphinx_rtd_theme

# Unter SLES / RHEL

sudo dnf groupinstall "Development Tools"
sudo dnf install ncurses-devel hmaccalc zlib-devel binutils-devel elfutils-libelf-devel

# 4. Day-2 Operations: Patching

Änderungen sicher einpflegen.

Admins müssen oft Patches einspielen (z.B. für neue Hardware oder Security-Fixes).

# Einen Patch anwenden

cd linux/
# -p1 entfernt das erste Verzeichnis aus dem Pfad im Patch-File
patch -p1 < my_security_fix.patch

# 5. Troubleshooting & “War Stories”

Wenn der Quellcode den Speicher frisst.

# Story 1: “Der Disk-Space-Schock”

Symptom: Der Build bricht nach 30 Minuten mit No space left on device ab. Ursache: Der entpackte Source-Tree braucht ca. 1GB. Aber während des Kompilierens entstehen hunderte .o (Object) Dateien. Ein Full-Build mit allen Modulen kann über 30GB Platz benötigen. Lösung: Nutzen Sie make localmodconfig (Artikel 237), um die Anzahl der kompilierten Module drastisch zu reduzieren, oder nutzen Sie eine dedizierte Build-Partition.

# Story 2: “Das falsche Repository”

Symptom: Der Admin kompiliert den Kernel 6.5, stellt aber fest, dass seine Proxmox-Module (ZFS) nicht funktionieren. Ursache: Der Admin hat den “Mainline” Kernel von Linus genommen. Distros wie Proxmox oder SLES nutzen jedoch angepasste Versionen mit hunderten eigenen Patches. Lösung: Nutzen Sie immer die Quellcode-Pakete Ihrer Distribution (linux-source oder kernel-source), wenn Sie die volle Kompatibilität zum Rest des Systems brauchen.

# 6. Fazit & Empfehlung

• Versionierung: Nutzen Sie Git für die Verwaltung Ihres Kernel-Trees. Es erlaubt das saubere Tracken von Änderungen und Patches.
• Minimalismus: Kompilieren Sie nur das, was Sie brauchen. Jedes unnötige Modul in drivers/ erhöht die Kompilierzeit und die Angriffsfläche.
• Doku: Die wichtigste Dokumentation liegt im Ordner Documentation/ im Source-Tree.

# Anhang: Cheatsheet