© Pop Nukoonrat, 123RF

Das Linux-Magazin hat den langjährigen Kernel-Entwickler Greg Kroah-Hartman unter anderem gefragt, wie Neulinge oder routinierte C-Entwickler am besten in die Kernel-Entwicklung einsteigen.

Linux-Magazin: Für Leser, die dich nicht kennen: Wie lange arbeitest du am Linux-Kernel, und wie beeinflusst das deine tägliche Arbeitsroutine?

Greg Kroah-Hartman: Im Vergleich zu vielen anderen Kernel-Core-Entwicklern habe ich erst ziemlich spät angefangen, zu Linux beizutragen. Meine ersten Patches wurden 1997 oder 1998 eingepflegt. Ich hatte Linux zuvor bereits eine Weile verwendet, aber bis dahin nicht die Zeit gehabt, daran mitzuarbeiten.

Ich betreue zurzeit die stabilen Kernel-Releases, die ich ein- oder zweimal pro Woche veröffentliche. Zugleich bin ich Maintainer für verschiedene Treiber-Subsysteme. Daneben programmiere ich mitunter, um Code aufzuräumen und den Kernel für neue Features vorzubereiten. Ich gehöre auch zum Kernel-Security-Team, daher liefere ich Ersteinschätzungen und kleine Bugfixes für Probleme, die andere dieser Gruppe berichten.

Meine tägliche Routine umfasst das Lesen sehr vieler E-Mails. Ich denke, es läuft auf ungefähr 1000 pro Tag hinaus, mit denen ich mich beschäftigen muss – sie überfliegen und archivieren oder sie ordnen und für eine spätere Prüfung zurückhalten.

Nach dem Einordnen entscheide ich entweder, an einer spezifischen Sache zu arbeiten, etwa den Patches für den stabilen Kernel oder Subsystem-Patches. Also wähle ich die entsprechende Mailbox aus und bearbeite sie. Ich habe in einem älteren Blogpost [1] und in deutlich zu viel Detailtiefe dokumentiert, wie ich Reviews abhalte und Patches handhabe, falls es jemanden interessiert.

Greg Kroah-Hartman auf dem Open Source Summit Europe 2019.

LM: Angenommen, ich arbeite für einen Gerätehersteller und soll Unterstützung für ein Gerät in den Linux-Kernel bringen. Ich bin die arme Seele, die den Treiber schreiben und mit den Kernel-Entwicklern reden soll. Wie gehe ich das an: Frage ich erst einmal nach der groben Marschrichtung, oder lese ich mich zunächst intensiv in das Thema ein?

GKH: Wenn du keine Erfahrung in Linux-Kernel-Entwicklung hast, dann ja: Lies intensiv! Wir haben haufenweise Dokumentation, die sich mit dem kompletten Entwicklungsprozess beschäftigt, angefangen bei einem simplen How-to [2]. Das bietet Links zu fast allem, was man wissen wollen könnte.

Eine ebenfalls empfehlenswerte Lektüre dreht sich darum, wie der komplette Entwicklungsprozess funktioniert [3]. Die ist nötig, um zu verstehen, gegen welche Kernel-Trees ein Entwickler testen sollte, wie der Release-Zyklus aussieht und wie – bezogen darauf, wie wir den Kernel tatsächlich entwickeln – all diese Dinge zusammenpassen.

Hast du alle Texte gelesen, empfehle ich, die Entwickler-Mailing-Liste für das passende Subsystem zu abonnieren, in die das Gerät gehört, an dem du arbeitest. Eine Liste all dieser Mailing-Listen liefert die »MAINTAINERS«-Datei im Wurzelverzeichnis des Kernel-Quellcodes.

Die dort geposteten Nachrichten geben dir einen Eindruck davon, wie du Code posten solltest, wie du die Dinge formatieren kannst und wer gute Reviews gibt. Sie zeigen auch, welche andere Subsystem-spezifischen Dinge du eventuell beachten musst, wenn du die für dein Gerät nötigen Änderungen einpflegst.

Wenn du schließlich einige Änderungen hast, die du gern in den Kernel einbringen möchtest, ist es zudem essenziell zu lesen, wie das überhaupt funktioniert [4].

LM: Der Kernel ist hauptsächlich in C geschrieben, und C ist eine ziemlich komplizierte und Low-Level-Sprache verglichen mit anderen …

GKH: C ist eine sehr einfache Sprache – ich habe lange nicht mehr gehört, dass jemand sie als “kompliziert” bezeichnet.

LM: … oder anders gefragt: C fehlen bestimmte Features, die andere Sprachen mitbringen, und die mitunter nützlich sein können. C ist nicht typsicher, Memory Management und Garbage Collection sind schwieriger umzusetzen. Daher beanspruchen andere Sprachen, bequemer für Programmierer zu sein, weil sie Dinge automatisieren.

GKH: C ist typsicher. Gut, das lässt sich umgehen, wenn du weißt, was du tust, wie bei jeder guten Low-Level-Sprache. Aber wir machen das fast nie im Kernel.

Und ja, andere Sprachen erlauben es dir, dich nicht um Dinge wie Garbage Collection und Memory Management kümmern zu müssen. Aber wenn du den Kerncode für ein System schreibst, das mit Memory Management umgehen muss, musst du auf Sachen wie diese achten. du kannst sie nicht ignorieren und hoffen, dass die Entwickler der Laufzeitumgebung der Sprache dir diese Arbeit abnehmen.

LM: Ist der Mangel an Automatisierung in C ein Nachteil, wenn es darum geht, neue Kernel-Entwickler zu finden, oder könnte es in Zukunft einer werden?

GKH: Um neue Entwickler zu finden – nein, glaube ich nicht, weil es eine einfache Sprache ist, die sich einfach lernen lässt. Über die Zukunft mache ich keine Vorhersagen, sorry!

LM: Genügt es, ein paar Übungsstunden in C zu nehmen, um Kernel-Entwickler zu werden? Oder würdest du die Kernel-Entwicklung eher erfahreneren Programmierern mit solidem C-Wissen empfehlen?

GKH: Man braucht solides C-Wissen für die Kernel-Entwicklung. Die sollte nicht das erstes Projekt sein, wenn man die Sprache lernt. Am besten lernt man die Sprache über Userspace-Programme, die viel mehr Infrastruktur in Form von etablierten Bibliotheken, einfaches Debuggen und eine wesentlich nachsichtigere Umgebung bieten. Ein Fehler in einem in C geschriebenen Userspace-Programm bringt eine Maschine nicht zum Rebooten, anders als ein Fehler im Kernel.

LM: Was ist aus deiner Perspektive die größte Herausforderung, der angehende Kernel-Hacker heute gegenüberstehen?

GKH: Etwas zu tun zu finden! Es gibt eine Menge von Einsteigeraufgaben und Tutorials da draußen. Aber der Schritt von “Ich habe einen Schönheitsfehler im Code behoben” zu “Hier ist eine echte Aufgabe, um daran zu arbeiten” ist schwierig. Manchmal lässt sich nur schwer etwas finden, an dem man arbeiten kann, wenn einem niemand eine spezifische Aufgabe zuweist.

In diesem Fall würde ich empfehlen, sich bei der Mailing-Liste des Subsystems anzumelden, das einen interessiert, und zu beobachten, über welche Probleme die Teilnehmer dort berichten. Das ist ein großartiger Weg, um auf echte Bug Reports zu stoßen, mit Code Reviews zu helfen und Probleme zu finden, an denen man arbeiten und die man reparieren kann.

LM: Einige Projekte markieren Bugs oder Feature Requests als “Good First Issue”, um Menschen zu ermutigen, sich am Projekt zu beteiligen. Existiert so etwas für den Kernel?

GKH: Ja, es gibt eine Reihe von “Hausmeistertätigkeiten”, die sich auf der Kernel-Newbies-Webseite [5] finden. Und wir listen eine Menge an To-do-Aufgaben in Dateien unter »drivers/staging/*/TODO« im Kernel-Quellcode-Zweig auf. Die sollen Anfängern helfen, in den Prozess einzusteigen.

LM: Weil Maschinen heute mehr Ressourcen mitbringen und weil sich die Cloud-Native-Entwicklung vor allem auf Container und VMs stützt: Gibt es noch viele Unternehmen, die ihre eigenen Kernel bauen oder Kernel an die eigenen Bedürfnisse anpassen? Oder herrscht eine stärkere Nutzung von unveränderten Kerneln vor?

GKH: Es ist immer besser, einen angepassten Kernel zu bauen, wenn du weißt, welche Hardware er genau unterstützen soll. Von den Distros bereitgestellte Kernel sind auf den kleinsten gemeinsamen Nenner abgestimmt. Wenn du weißt, dass du den neuesten Prozessortyp einsetzt, bringt es mitunter einen realen und messbaren Performance-Schub, wenn du den Kernel dafür baust.

Nutzt du ein Embedded-System, ist es grundsätzlich sinnvoll, nur den Support für die im System genutzte Hardware einzubauen. Du willst keinen Speicherplatz für Treiber und Features verschwenden, die du nie einsetzen wirst.

LM: Was sind aus deiner Perspektive aktuell die interessantesten Baustellen, die die Zukunft des Kernels prägen?

GKH: Ich bin sicher, du hast schon davon gehört, dass eBPF langsam den Kernel übernimmt und wie der Userspace damit interagiert. Es ist beeindruckend, die Änderungen in diesem Subsystem anzuschauen, das mehr und mehr Kernel-Bereiche integriert.

Andere interessante Bereiche resultieren aus der Arbeit an »io_uring« von Jens Axboe. Das eröffnet einen neuen Weg für den Userspace, Daten auszutauschen, ohne Syscalls zu verwenden. Die Arbeit ergänzt neue Features für Userspace-Programmierer, um einen erstaunlich hohen Datendurchsatz zu erreichen, der vorher so nicht möglich war.

LM: Denkst du, der Kernel selbst sollte in verschiedenen Geschmacksrichtungen vorliegen, wie es einige Linux-Distros anbieten, um verschiedenen Workloads gerecht zu werden?

GKH: Machen Distros das noch? Wie schon erwähnt, ist es gut, Kernel zu bauen, die auf spezifischen Hardware-Typen laufen. Das spart Platz und verbessert die Performance, wenn du genau weißt, was für Hardware du einsetzt. Der Kernel bietet dir sehr fein abgestufte Möglichkeiten, ihn für solche Fälle anzupassen.

Manche argumentieren allerdings, das sei zu kleinteilig, und es müsse einen einfacheren Weg geben, um einen Build mit einem bestimmten Set an Features zu konfigurieren. Dagegen hat niemand etwas – es muss nur jemand vortreten und die Arbeit auf sich nehmen, um diese Idee umzusetzen.