# Kernel Development: Den Core aktiv mitgestalten

TL;DR / Management Summary Der Linux-Kernel ist das größte Open-Source-Projekt der Welt. Wer daran mitarbeiten will, muss den “Way of the Kernel” verstehen: Keine Pull-Requests auf GitHub, sondern E-Mails an Mailing-Listen. Strikte Coding-Styles und der Einsatz von Tools wie checkpatch.pl sind Pflicht. Dieses Modul zeigt Ihnen, wie Sie Ihren ersten Patch vorbereiten, signieren und an die richtigen Maintainer senden.

# 1. Einführung & Architektur

Der Release-Zyklus.

Linus Torvalds veröffentlicht ca. alle 9-10 Wochen einen neuen Kernel.

  1. Merge Window (2 Wochen): Neue Features werden gemerged.
  2. Release Candidates (RC1-RC8): Bugfixing-Phase.
  3. Final Release: Der neue stabile Kernel erscheint.

# Architektur der Review-Prozesse

Jedes Subsystem (Netzwerk, Filesysteme, ARM-Architektur) hat eigene Maintainer. Ihr Patch muss erst deren Segen erhalten, bevor er im Hauptzweig (mainline) landet.

# 2. Vorbereitung der Umgebung

Die Werkzeuge des Schmieds.

# 1. Quellcode klonen

Arbeiten Sie immer gegen den linux-next Tree, wenn Sie neue Features planen, oder mainline für Bugfixes.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux

# 2. Email-Setup

Der Kernel-Prozess nutzt Plain-Text E-Mails. git send-email ist das Tool der Wahl. Konfigurieren Sie Ihren SMTP-Server in der .gitconfig.

# 3. Den Patch erstellen

Qualität vor Quantität.

# Schritt 1: Code schreiben & Coding Style prüfen

Linux hat einen sehr spezifischen Style (Tabs statt Leerzeichen, 80 Zeichen Limit).

# Prüfen Sie Ihren Patch vor dem Absenden!
./scripts/checkpatch.pl 0001-my-fix.patch

# Schritt 2: Sign-off

Jeder Patch braucht eine rechtliche Bestätigung (Developer's Certificate of Origin).

git commit -s -m "subsystem: description of my fix"

Das -s fügt die Zeile Signed-off-by: Your Name <email> hinzu.

# 4. Deep Dive: Patches einreichen

Den richtigen Empfänger finden.

# Wer ist zuständig?

Nutzen Sie das get_maintainer.pl Script:

./scripts/get_maintainer.pl my_fix.patch
# Output: Maintainer Name <email>, L-List <email>

# Senden

git send-email --to maintainer@kernel.org --cc linux-kernel@vger.kernel.org 0001-my-fix.patch

# 5. Troubleshooting & “War Stories”

Warum Patches abgelehnt werden.

# Top 3 Fehler

  1. Fehler: HTML E-Mails oder Base64-Attachments.

    • Folge: Der Patch wird von den automatischen Systemen ignoriert.
    • Lösung: Nur Plain-Text verwenden!

  2. Fehler: Fehlende Beschreibung des “Warum”.

    • Lösung: Erklären Sie im Commit-Log nicht, was der Code macht (das sieht man), sondern warum die Änderung nötig ist.

  3. Fehler: Patch basiert auf einer uralten Kernel-Version.

    • Lösung: Immer git rebase auf den aktuellen Master.

# “War Story”: Der vergessene Tab

Ein bekannter Entwickler reichte einen 500-Zeilen Patch für ein neues Filesystem-Feature ein. Der Patch wurde abgelehnt, weil er an einer Stelle Leerzeichen statt Tabs verwendet hatte. Lehre: Im Kernel-Umfeld ist Disziplin bei der Formatierung ein Zeichen für Disziplin bei der Logik. Nutzen Sie die mitgelieferten Scripts!

# 6. Day-2 Operations: Feedback-Runden

Kritik ist ein Geschenk.

Maintainer werden Ihren Code kritisieren. Das ist normal.

  1. V1: Erster Entwurf.
  2. V2: Überarbeiteter Entwurf nach Feedback. (Betreff: [PATCH v2] ...)
  3. Merged: Ihr Name steht für immer in der git log Historie.

# 7. Fazit & Empfehlung

Kernel-Entwicklung ist die “Königsdisziplin”.

# Anhang: Cheatsheet

Tool Zweck
scripts/checkpatch.pl Style-Check
scripts/get_maintainer.pl Empfänger finden
git format-patch Erstellt Patch-Dateien
git send-email Versendet Patches
make -j$(nproc) Kernel schnell kompilieren

# Referenzen