Ein Kernel-Zyklus dauert acht bis zehn Wochen. Die Entwicklung folgt dabei einem eingespielten Schema.

Der Betriebssystemkern Linux ist das größte und zweifelsfrei einflussreichste Projekt aus dem Bereich der freien Software. Linux hat die Welt im positiven Sinn verändert, und es erleichtert nach wie vor das Leben vieler Menschen. Alle acht bis zehn Wochen bescheren die Entwickler den Anwendern eine neue Version des Kernels. Dabei überschreiten sie in letzter Zeit regelmäßig die Zahl von 10?000 Patches, die im Schnitt von rund 1600 Entwicklern stammen, die wiederum für etwa 200 Unternehmen arbeiten.

Die derzeitige Bearbeitungsrate beträgt atemberaubende acht Änderungen pro Stunde. Doch wie bewältigt eine lose organisierte Gemeinschaft diese Last? Was passiert genau während eines solchen Zyklus, und welche Probleme müssen die Entwickler dabei lösen?

Bei Kernel-Entwicklern handelt es sich heute zunehmend um festangestellte Programmierer aus Unternehmen. Ihre Arbeitgeber haben auf die eine oder andere Weise ein Interesse an der Arbeit am Kernel und stellen daher einen oder mehrere Angestellte in Vollzeit oder auf der Basis von Teilzeit dafür ab (Abbildung 1).

Abbildung 1: Die Zahl der Codezeilen im Kernel steigt ständig. (Bild: Linux Foundation)

Individuelle Entwickler – früher in der Mehrzahl – tragen heute immer seltener zum Kernel bei. Das hat den positiven Hintergrund, dass Programmierer, die erfolgreich Code für den Kernel einreichen, nicht lange Privatiers bleiben: Sie erhalten sehr schnell lukrative Job-Angebote.

Als prominentes Beispiel sei hier Chris Mason genannt, der Entwickler des Dateisystems Btrfs. Er arbeitet heute für das US-Unternehmen Facebook, das ihn komplett für dessen Weiterentwicklung abstellt: Der Social-Media-Gigant setzt das Dateisystem, das mehr Funktionalität aufweist als andere, auf breiter Fläche im Backend ein.

Dabei handelt es sich um eine klassische Win-Win-Situation, von der sowohl Facebook als auch Mason und die Linux-Anwender profitieren. Facebook steht so ständig an der Spitze der Entwicklung, Mason hat eine Entwicklungsumgebung mit vielen Tausend Rechnern, und die Anwender profitieren direkt von den Neuerungen, die in fast jede frische Kernel-Version einfließen (Abbildung 2).

Abbildung 2: Chris Mason entwickelt als Angestellter von Facebook am Dateisystem Btrfs. So profitieren beide Seiten von der Arbeit des Programmierers. (Bild: Swapnil Bhartiya, CC BY)

Pyramide

Es lohnt sich, einen Blick auf die Struktur und den generellen Workflow zu werfen, denen die Arbeit der Entwickler unterliegt. Alle Teilnehmer befinden sich in einer klassischen Hierarchie. An deren Spitze steht Linus Torvalds als wohlmeinender, aber oft ein wenig cholerisch veranlagter Diktator. Darunter folgt sein zweiter Mann, Greg Kroah-Hartman (GKH).

Danach geht die Pyramide schnell in die Breite, dort sitzen die verantwortlichen Entwickler für die Kernel-Subsysteme. Zu den wichtigsten Subsystemen des Kernels zählen Gerätetreiber, Netzwerk-Stack, Speichermanagement, Dateisysteme, USB, Energieverwaltung, Scheduler und Hardware-Architekturen wie ARM. Die Subsysteme teilen sich jeweils weiter auf. Die Basis der Pyramide bilden die Entwickler, die Patches an die Betreuer der Subsystem-Teile übergeben (Abbildung 3).

Abbildung 3: Die hierarchische Struktur der Kernel-Entwicklung ist organisch gewachsen und bewährt sich bis heute.

Patch als kleinste Einheit

Ein Patch bildet die kleinstmögliche Einheit, die eine einzige Änderung am Quellcode des Kernels umfasst. Die Patches steigen über eine Vertrauenskette an die Spitze der Pyramide. Torvalds kennt die Pfleger der Subsysteme und vertraut darauf, dass sie Patches erst testen, bevor sie diese an ihn weiterreichen. Als Maßgabe gilt hier, dass der Kernel nach Hinzufügen des Patches noch funktioniert.

Es gibt gelegentlich aber auch disruptive Änderungen, die jedoch – so Torvalds oberste Devise – niemals den User-Space beeinträchtigen dürfen. Das gilt für die GNU C Standard-Laufzeit-Bibliothek Glibc [1] und die Anwendungen, alle Komponenten darunter liegen im Kernel-Space. Die Glibc stellt die Schnittstelle für Systemaufrufe dar und wickelt Kommunikation zwischen Kernel- und User-Space ab (Abbildung 4).

Abbildung 4: Die Glibc trennt Kernel-Space und User-Land.

Als Mittel der Wahl beim Einreichen von Patches gilt die E-Mail – das Medium steht nahezu überall bereit. Die Entwicklergemeinde des Kernels verteilt sich über den Erdball, nicht jeder verfügt über eine gute Anbindung ans Internet. Zudem sind einige Kernel-Entwickler blind, ihnen kommt E-Mail als Medium zum Übermitteln von Code besonders entgegen. Außerdem arbeitet die Entwicklergemeinde oft mobil und ist viel auf Reisen. Hier spielt die überall leicht erreichbare E-Mail ihre Stärken aus.

Immer wieder sonntags

Neun oder zehn Wochen nach dem Erscheinen eines aktuellen Kernels und meist an einem Sonntag gibt Linus Torvalds eine neue Version des Kernels frei. Vorher gab es in der Regel sieben oder acht Vorabversionen, die sogenannten Release Candidates (RCs).

Mit der Freigabe des neuen stabilen Kernels ist die Arbeit daran aber nicht abgeschlossen: Ab hier übernimmt Greg Kroah-Hartman (Abbildung 5). Er agiert neben seinen zahllosen weiteren Aufgaben [2] auch als Maintainer des “Stable”-Zweigs und pflegt ständig weitere Patches ein, die im Betrieb entdeckte Fehler beheben.

Abbildung 5: Greg Kroah-Hartman übernimmt zahlreiche Aufgaben rund um den Kernel. Unter anderem kümmert er sich um die Pflege der stabilen Version. (Bild: Sebastian Oliva, CC BY-SA 3.0)

Die normale Lebenszeit einer Kernel-Version erstreckt sich über zwei bis drei Monate. Jedes Jahr sucht sich Kroah-Hartman jedoch ein Kernel-Release heraus, das er in die Long Term Support Initiative (LTSI) übernimmt. Diese Version erhält dann rund zwei Jahre lang Fehlerbereinigungen und Sicherheits-Patches.

Selbst danach dürfen manche Kernel-Versionen noch nicht in den Ruhestand. Andere Betreuer übernehmen dann die Pflege, etwa weil Unternehmen gerade diese Version benötigen. Auf der Kernel-Webseite finden Sie eine Liste der noch unterstützten Varianten. Hier kann man unter anderem nachlesen, dass der im Juni 2012 erschienene Kernel 3.2 im Februar 2017 eine Aktualisierung auf Version 3.2.86 erfuhr.

Zwei Wochen Zeitfenster

Aber zurück zum Sonntag, an dem Torvalds in aller Regel einen neuen Kernel als stabil freigibt (Abbildung 6): Hier beginnt für den Herrn der Kernel der neue Zyklus zur nächsten Kernel-Version. Es öffnet sich ein zweiwöchiges Zeitfenster, das sogenannte Merge Window.

Abbildung 6: Sonntags gibt Linus Torvalds neue Kernel frei, die Veröffentlichungen unterliegen einem strengen Zyklus. (Bild: Krd, CC BY-SA 3.0)

In diesem Zeitraum reichen die Subsystem-Betreuer die bisher von ihnen akzeptierten Änderungen für den nächsten Kernel ein. Die Entwickler arbeiten also schon länger an Änderungen für eine neue Version. Diese Arbeit findet im Zweig linux-next statt, der künftige Änderungen sammelt. Die nimmt Linus Torvalds dann während des Merge Window in den “Main”-Zweig auf.

Code kann durchaus länger als einen Zyklus in linux-next liegen. Während dieser Zeit fügen die Subsystem-Betreuer die Patches ins entsprechende Git-Repository ein und bauen probehalber Kernel auf dieser Basis. Das Einreichen von Änderungen in linux-next führt allerdings nicht zwangsweise zur Aufnahme in den Kernel.

Die meisten Patches erhält Torvalds in den ersten Tagen des Merge Window. Dabei entfallen im Durchschnitt rund zwei Drittel der Änderungen auf die Sektion Gerätetreiber, wobei hier wiederum die Grafiktreiber den größten Anteil ausmachen. Mit dem Schließen des Fensters veröffentlicht Torvalds den ersten Kandidaten für die Veröffentlichung, der dann den Zusatz -rc1 trägt.

Darauf folgen Woche für Woche weitere Versionen, bis Torvalds von der Qualität überzeugt ist und sich zur Freigabe entschließt. Die Zeiträume liegen hier nicht explizit fest, haben sich aber über die Jahre bei acht bis zehn Wochen eingespielt.

Seltener Eingriff

Haben Sie jetzt den Eindruck, dass Linus Torvalds nicht mehr direkt an der Kernel-Entwicklung teilnimmt, so stimmt das – bedingt. Er überprüft im Gegensatz zu seinen Kollegen an der Spitze der Pyramide nur einen verschwindend kleinen Teil der eingereichten Patches. Das haben bereits die Subsystem-Maintainer erledigt, denen er vertraut. Torvalds schreibt darüber hinaus keinen Code für den Kernel mehr, editiert aber ab und zu Patches, die ihm nicht gefallen.

Er hat allerdings das letzte Wort, wenn es um die Aufnahme in den “Main”-Zweig geht. So kann er beispielsweise Patches selbst dann ablehnen, wenn ein Subsystem-Betreuer sie durchgewunken hat. Das geschieht sogar im Alleingang, wenn er mit der Materie im Detail ausreichend vertraut ist. Oft geht dem aber eine Diskussion auf der Kernel-Mailing-Liste LKML [3] oder bei mehrmals jährlich stattfindenden Konferenzen voraus.

Fehler kommen vor

Ab dem dritten RC im jeweiligen Zyklus erweisen sich die Kernel üblicherweise als stabil genug für eine breite Masse an Testern. Die tragen mit ihren Bug-Reports im Gegenzug dazu bei, dass der Code sich weiter stabilisiert. Das System funktioniert größtenteils wie eine gut geölte Maschine. Doch selbst hier passieren Fehler, und dann weist ein stabiler Kernel einen Bug auf, der Anwender betrifft.

Das geschah zuletzt bei Kernel 4.8, der einen so gravierenden Fehler aufwies, dass Systeme abstürzten. Der fragliche Patch gelangte erst kurz vor der Veröffentlichung in das Repository, abgesegnet vom langjährigen und prominenten Kernel-Entwickler Andrew Morton [4]. In solchen Situationen kommt dann Torvalds berüchtigter und oft kritisierter Führungsstil zum Vorschein: Er kanzelt die Kollegen mit oft sehr drastischen Worten ab. In diesem Fall schimpfte er zunächst wie ein Rohrspatz über den “dummen Fehler” und maulte dann, von Morton hätte er eigentlich mehr erwartet [5]. Der nahm die herbe Kritik gelassen hin und entschuldigte sich (Abbildung 7).

Abbildung 7: Auch alte Hasen aus dem inneren Zirkel wie Andrew Morton machen Fehler, die Linus Torvalds dann gern mit deutlichen Worten quittiert. (Bild: Ilya Voyager, CC BY-SA 3.0)

Torvalds rechtfertigt seinen Stil, der in solchen Situationen mitunter in persönliche Beleidigungen ausartet, damit, dass er eine klare und direkte Sprache bevorzugt: Leise Worte und versteckte Kritik würden hier nichts bewirken, meint er. Die meisten Entwickler nehmen seinen Stil hin oder befürworten ihn sogar.

Insgesamt treten solche Fehler eher selten auf. Ab und zu kommt es jedoch vor, dass Änderungen nach teils langen und heftigen Diskussionen unter den Entwicklern in den Papierkorb wandern oder erneut aufs Reißbrett kommen.

Akte Kdbus

In solchen Fällen zeigt sich Torvalds von einer anderen Seite: Er nimmt sich zurück und sieht sich zunächst die Argumente der Entwickler-Kollegen an. Der letzte Fall, in dem es Patches zu einem größeren Projekt letztlich nicht in den Kernel schafften, war die geplante Aufnahme von Kdbus in den “Main”-Zweig. Das Projekt wollte die Interprozess-Kommunikation (IPC) von D-Bus [6] aus dem Userspace in den Kernel verlagern.

Bereits vorher waren einige Versuche gescheitert, eine IPC im Kernel zu verankern [7]. Das Projekt Kdbus stammte aus dem Umfeld der Entwickler von Systemd. Greg Kroah-Hartman, Torvalds Generalissimo, befürwortete die Idee, und nach rund zwei Jahren Entwicklung entstand im Oktober 2014 eine Patch-Serie für Kernel 4.1. Kroah-Hartman schrieb dazu in seinem Pull-Request auf der Kernel-Mailing-Liste (LKML) [8]: “Kdbus wird seit Jahren entwickelt, befindet sich seit Monaten in linux-next und durchlief eine Menge an Tests und Reviews. Es ist voll dokumentiert und getestet.”

Dessen ungeachtet entbrannten heftige Diskussionen unter den Kernel-Entwicklern [9], was die Kdbus-Fraktion einigermaßen überraschte. Das Projekt hatte bereits im Vorfeld für viel Gesprächsstoff gesorgt, und sie glaubten alle Streitpunkte ausgeräumt. Einem Teil der Argumente fehlte es tatsächlich von Anfang an Substanz: Sie kamen aus dem Lager der grundsätzlichen Gegner von Lennart Poettering und seinem Projekt Systemd.

Die technischen Argumente gegen Kdbus reichten von der infrage gestellten generellen Sinnhaftigkeit über den Wunsch einer allgemeineren Lösung ohne D-Bus. Hinzu gesellte sich Kritik an der Performance, den bei jeder Nachricht mitgesendeten Metadaten und dem Einsatz der bei vielen Entwicklern unbeliebten Capabilities [10].

Kroah-Hartman zog daraufhin die Patches für Kernel 4.1 zurück [11] und sagte zu, bei einigen der Kritikpunkte nachzubessern. Erst zu diesem Zeitpunkt schaltete sich Torvalds öffentlich in die Debatte ein: Generell sei er für die Aufnahme von Kdbus, weil die Patches von seinem wichtigsten Sub-Maintainer Greg Kroah-Hartman stammten – das habe bei ihm eine Menge Gewicht [12].

Darüber hinaus vertrat er aber auch die Meinung, die Leistungsfähigkeit der Software sei nicht voll ausgeschöpft. Die Tatsache, dass der entsprechende Userspace-Code des bestehenden Systems von einem “zurückgebliebenen Affen auf Crack” stamme, sei per se noch kein Grund, anderen Code in den Kernel aufzunehmen. Der Kernel-Code müsse generell höheren Maßstäben genügen, daher sei er in der Regel leistungsfähiger. Dabei handle es sich aber keineswegs um einen Automatismus.

Nachdem es Kdbus wegen anhaltender Kritik nicht in die folgenden Kernel-Versionen 4.2 und 4.3 schaffte, zogen Kroah-Hartman und die Systemd-Entwickler den Code aus Fedora “Rawhide”, wo er zum Testen vorlag, und aus linux-next komplett zurück. Sie begannen eine neue Implementation, die unter dem Namen Bus1 [13] läuft und irgendwann in den Kernel einzieht – oder auch nicht.

König Torvalds

Die Kernel-Entwicklung gilt als Königsklasse für Linux-Programmierer. König im Kernel-Land ist und bleibt Linus Torvalds, der mit seinen verbalen Ausfällen oft die Grenzen des guten Geschmacks überschreitet, sich aber andererseits auch gelegentlich demokratisch in die Reihen seiner Entwickler stellt und deren Argumenten folgt. Letzteres findet naturgemäß weniger Beachtung als die öffentlichkeitswirksamen verbalen Ausfälle.

Für Außenstehende verbleibt der Eindruck einer gut geölten Maschine, die Kernel wie am Fließband hervorbringt. Die größte Bedrohung für diesen reibungslosen Ablauf: Im Gegensatz zur ständig wachsenden Zahl der Patches steigt der Bestand an Entwicklern kaum noch an (Abbildung 8).

Abbildung 8: Die Zahl der Entwickler hält mit dem Wachstum des Kernels nicht Schritt.

Viele Maintainer beschweren sich über zu viel Arbeit, Entwickler wie Dan Vetter [14] und Wolfgang Sang [15] tragen das Problem seit Jahren auf Vorträgen in die Öffentlichkeit. Zwar werde die anstehende Arbeit erledigt, doch leide zunehmend die Qualität unter der Überlastung, beklagen sie.