Die Kernelentwicklung startete als ein Rinnsal, gespeist allein von Linus Torvalds – nach seiner Meinung "nichts Großes". Der heutige Strom aus Millionen Zeilen C-Code, der die IT-Landschaft nachhaltig durchschneidet, wäre ohne eine Mischung aus straffer Organisation und uneigennütziger Mitarbeit unmöglich.

Der Linux-Kernel gilt als gut funktionierendes, komplexes und gut dokumentiertes Paradebeispiel für Open-Source-Software: Jeder hat Zugriff auf den tagesaktuellen Quelltext und kann auf der Mailingliste mitdiskutieren oder Patches vorschlagen. Dass es in einem Softwareprojekt mit mehreren Millionen Zeilen Code klar verteilte Aufgabenbereiche, Kompetenzen und Strukturen gibt, ist wenig überraschend, auch wenn dies gelegentlich abschreckend auf potenzielle Neueinsteiger wirkt.

Kopf der Truppe

Die Kernelentwicklung stand und steht unter der Leitung von Linus Torvalds (Abbildung 1). Qualitativ betrachtet ist er zwar nicht mehr der Hauptentwickler des Code, doch koordiniert er noch immer die Veröffentlichungen und die Arbeit am Kernel und beteiligt sich in den Mailinglisten auch rege an Diskussionen über neue Funktionen. Der Maintainer der aktuellen Reihe 2.6 des Kernels ist Andrew Morton (Abbildung 2).

Abbildung 1: Linus Torvalds auf dem Kernel-Summit 2007: Der geistige Vater des Linux-Kernels ist weiterhin maßgeblich an der Entwicklung beteiligt.

Abbildung 2: Andrew Morton gilt als Nummer zwei in der Kernelentwicklung. Sein »-mm«-Zweig ist richtungweisend für neue Features des Linux-Kernels.

Ein Maintainer ist der Hauptverantwortliche eines Projekts. Er entscheidet, meist in Abstimmung mit anderen Entwicklern, über die weitere Vorgehensweise. Neben der Kernelreihe 2.6 betreut Morton einzelne Unterprojekte wie die Entwicklung des Netdev-Treibers oder der Dateisysteme Ext 3 und Ext 4.

Ansprechpartner

Wie der Kernel insgesamt oder der 2.6-er Zweig für sich hat fast jeder Teilbereich des Kernels einen eigenen Maintainer. Um wen es sich genau handelt und wie er oder sie zu erreichen ist, zeigt das Dokument »MAINTAINERS« im Hauptzweig des Kernel-Quellpakets [1].

Bei der Lektüre des Dokuments fällt auf, dass an einigen Stellen keine Person benannt ist und gleichzeitig in der Spalte »s« wie Status »orphan« steht. Hier handelt es sich um Bereiche, die gegenwärtig niemand aktiv betreut. Selbstverständlich freut sich die Entwickler-Community, wenn jemand die Verantwortung für verwaiste Entwicklungsbereiche übernehmen möchte. Ein Maintainer sollte jedoch tiefgehende Fachkenntnisse mitbringen. Wer neu in der Kernelentwicklung ist, findet eher einen Einstieg, wenn er erst mal mit Bugfixes und Patches aushilft.

Baumstruktur

Das Verzeichnis »Documentation« beschreibt die einzelnen Zweige des Kernels [2]. Oberhalb der untergeordneten Zweige, der Subtrees, gibt es vier Hauptbäume: »main 2.6.x«, »2.6.x.y-stable«, »2.6.x-git« und »2.6.x-mm«. Linus Torvalds pflegt den »main 2.6.x«-Strang. Steht eine neue Kernelversion an, öffnet Torvalds ein zweiwöchiges Zeitfenster, in dem ihm alle Entwickler ihre Diffs zuschicken dürfen.

Fast immer waren Änderungen, die in den Main-Tree wandern sollen, bereits mehrere Tage oder Wochen im »-mm«-Kernel im Test. Gewöhnlich am Ende der zweiten Woche gibt Torvalds den ersten Veröffentlichungskandidaten (Release Candidate) heraus. Von diesem Zeitpunkt an sind größere Änderungen normalerweise ausgeschlossen, lediglich bei wichtigen Treibern und schwerwiegenden Sicherheitslücken macht Linus Torvalds Ausnahmen.

Läuft alles wie geplant, erscheinen im Wochenrhythmus weitere Release Candidates. Zwischen ihnen liegen kleine, oft nur kosmetische Korrekturen des Code. Nach dem sechsten RC ist es normalerweise geschafft: Die nächste stabile Version des Linux-Kernels ist fertig.

Im »2.6.x.y-stable«-Tree, also Kernelversionen mit vierstelliger Release-Nummer, gibt es meist nur kleine Änderungen, der Schwerpunkt liegt auf Sicherheits-Fixes. Dieser Ast gilt als besonders verlässlich. Ist kein Kernel mit vierstelliger Version verfügbar, zählt die höchste 2.6.x-Version als die jeweils stabilste.

Der Baum »2.6.x-git« ist dagegen ein täglicher Snapshot von Torvalds Kernel-Tree aus dem von Linus selbst initiierten Versionskontrollsystem Git [3]. Er ist von noch deutlich experimentellerem Charakter als ein Release Candidate. Die Schnappschüsse entstehen automatisch ohne Eingriff eines Entwicklers.

Mut zum Experiment

Andrew Morton pflegt den »2.6.x-mm«-Tree. Der unterschiedet sich von Torvalds Vanilla-Kernel durch noch ungetestete Änderungen von Morton selbst oder durch von ihm gesichtete Patches. Morton integriert in seinen Anpassungen Änderungen aller Subsysteme und Patches aus der Mailingliste.

Der »-mm«-Zweig gilt als Spielwiese für neue Entwicklungen und Features. Hat ein Patch hier seine Verlässlichkeit bewiesen, gilt seine Aufnahme in Torvalds Kernel-Tree als sehr wahrscheinlich. Wer bei der Kernelentwicklung mitarbeiten möchte, sollte daher vom »-mm«-Tree Gebrauch machen.

Auch die Maintainer der Subtrees betreuen oft mehrere Projekte gleichzeitig. So pflegt etwa der Deutsche Johannes Berg den neuen WLAN-Stack (Subtrees »SOFTMAC LAYER (IEEE 802.11), CFG80211 and NL80211«) des Kernels und kümmert sich gleichzeitig um den “Apple Onboard Audio”-Treiber für das Alsa-Framework, für das Jaroslav Kysela verantwortlich zeichnet.

Eine Sonderrolle unter den Kernelentwicklern nehmen die so genannten Janitors ein. Sie betätigen sich als eine Art Hausmeister und kümmern sich um vielerlei Kleinigkeiten, die während der Entwicklung anfallen. Zum einen sorgen sie für geordnete Verhältnisse, indem sie tote oder nicht mehr erreichbare Codebestandteile entfernen. So stellen sie sicher, dass die Größe der Codebasis des Kernels überschaubar bleibt. Zum anderen passen sie veraltete Schnittstellen an neue APIs an. Ziel ist dabei, die alten Schnittstellen verschwinden zu lassen. Einer der bekanntesten Janitors ist der Deutsche Adrian Bunk.

Offene Gesellschaft

Aller hierarchischen Organisation zum Trotz steht die Mitarbeit am Linux-Kernel grundsätzlich jedem offen. Sind einem Benutzer im Kernel Fehler oder funktionale Defizite aufgefallen, kann er jederzeit auf der Mailingliste Patches vorschlagen. Voraussetzungen, dass er damit Erfolg hat, sind natürlich die hervorragende Beherrschung der Programmiersprache C und ausreichend Erfahrung als Software-Entwickler.

Gestandene Kernelentwickler empfehlen Interessenten die Lektüre mehrerer Bücher, Vorschläge dazu geben sie im »Documentation/HOWTO« in den Kernelquellen. Auch verschiedene Webseiten wie [4] und [5] helfen beim Einstieg in die Kernelentwicklung.

Der Kernelcode folgt grundsätzlich dem ISO-C89-Standard, benutzt jedoch auch eine Reihe von Spracherweiterungen des GNU-Compilers [6]. Der Kernel ist größtenteils eine freistehende C-Umgebung, die prinzipbedingt nicht auf Standard-C-Bibliotheken basiert. Lediglich kleine Teilbereiche sind in Assembler verfasst.

Konstruktive Mitarbeit

Wer sich mit Bugreports und Patches an die Kernel-Community wenden möchte, sollte einige Regeln beachten: Patches müssen als Diff vorliegen. Nachdem der Einsender die Fehler klar eingegrenzt und schließlich behoben hat, ist der Maintainer des betroffenen Subsystems der richtige Ansprechpartner. Ohne Erklärung ist übrigens das beste Patch so gut wie wertlos. Eine Beschreibung des Fehlers, des Patches und seiner Auswirkungen erleichtert es dem Maintainer, sich mit den Vorschlägen auseinanderzusetzen und erhöht die Chance der Aufnahme in den Kernel.

Sätze wie “Das löst verschiedene Probleme …”, “Dieses Patch macht 2000 Zeilen Code überflüssig …” oder “Ich habe dieses Patch auf fünf Architekturen getestet …” lassen die Maintainer aufhorchen. Steht in der ankündigenden Mail dagegen: “Ich mach das schon seit zwanzig Jahren, also hört mal zu …” oder “Ich habe hier ein Patch von 5000 Zeilen …”, reagieren sie verständlicherweise eher genervt.

Außer einer aussagekräftigen Beschreibung sollten Einsender Folgendes beachten: Große Patches, die komplexe Probleme lösen, begutachten die Maintainer lieber und leichter, wenn sie als kleinere Teilpatches eingehen. Kurz vor Ende des Merge-Fensters haben sie selten noch Zeit, Änderungen von Newcomern unter die Lupe zu nehmen.

Da die Kernelentwickler Patches vor der Übernahme prüfen, sollten sie stets so einfach und transparent wie möglich gehalten bleiben. Unfertige Patches mit dem Versprechen, sie später zu fixen oder fertigzustellen, landen meist ohne Beachtung im Daten-Nirwana. Weitere Informationen bieten die Dokumente »applying-patches.txt«, »SubmittingPatches«, »SubmittingDrivers« und »SubmitChecklist« im Verzeichnis »Documentation« der Kernelquellen.

Abbildung 3: Chefsache: Linus selbst initiierte die Kernel-Versionsverwaltung Git.

Grenzenlose Kommunikation

Schon die Art der Kommunikation unter den Kernelentwicklern trägt zur Offenheit bei: Wer mitarbeiten möchte, muss nicht Zugriff auf das Intranet von Firma X haben. Schließlich arbeiten alle Beteiligten schon immer über den ganzen Globus verstreut und organisieren sich übers Internet. Die globale Zusammenarbeit der Kernelentwickler begann ja auch mit Linus\’ inzwischen legendärem Posting in der Minix-Mailingliste [7]. Bis heute läuft ein Großteil der Kommunikation über E-Mails und Mailinglisten.

Die wichtigste Liste ist die Linux Kernel Mailing List [8]. In ihr lassen sich alle aktuellen Diskussionen und Entwicklungen verfolgen. Auch der IRC ist Teil des globalen Kontakts. Andere Formen wie ICQ oder telefonische Kontakte spielen eine untergeordnete Rolle. Diese unpersönliche Form der Kommunikation hat Vor- und Nachteile. Als einen der größten Vorteile sehen die Beteiligten das Fehlen von Diskriminierung aufgrund des Geschlechts oder anderer oberflächlicher Merkmale.

Reibungsverluste

Als Nachteil erweisen sich immer wieder auftretende Missverständnisse. Die Diskussionen, in die Hans Reiser, der Entwickler des gleichnamigen Dateisystems, verwickelt war, erlangten wegen ihres harschen Tons und des vielfachen aneinander Vorbeiredens unrühmliche Bekanntheit in Entwicklerkreisen.

Auch der Australier Con Kolivas, hauptberuflich Arzt und bekannt geworden durch seine für einen nebenberuflichen Entwickler spektakulären Änderungsvorschläge am CPU-Scheduling-System [9], musste die Erfahrung machen, dass E-Mail-Kommunikation nicht immer einfach ist, und gab schließlich frustriert auf. Über die näheren Gründe für seinen Ausstieg aus der Kernelentwicklung gibt er in einem Interview in diesem Heft Auskunft. (pkr)