Linux-Kernel-Maintainer Andrew Morton zum Entwicklungsmodell

Große Softwareprojekte haben ihre eigenen Regeln, denn Hunderte von Entwicklern und Millionen Zeilen Code wollen koordiniert sein. Das Linux-Magazin fragte beim ranghöchsten Maintainer des aktuellen Linux-Kernels nach, wie er das bewerkstelligt.

Die Zahlen sind beeindruckend: Ungefähr 4300 Zeilen Code kommen zum Kernel hinzu, 1800 löschen die Entwickler und 1500 erfahren Änderungen – pro Tag. Das sind die Durchschnittswerte für das Jahr 2007, wie Greg Kroah-Hartman auf einer Konferenz mit Kernelentwicklern mitteilte. Die Zahlen steigen durchschnittlich um zehn Prozent jährlich.

Damit die Menge der Änderungen überhaupt handhabbar bleibt, hat sich die Entwicklergemeinde eine ausgeklügelte Infrastruktur und ein hierarchisches Modell ausgedacht, um die Quellen des freien Betriebssystems effizient zu verwalten.

Die von vielen kleineren Projekten verwendeten Programme zur Versionskontrolle (VCS) waren Linus Torvalds dazu nicht genug. Gerade wenn es darum geht, gleichzeitig unterschiedliche Teile des Code abzuspalten, um dort weitreichende Veränderungen vorzunehmen und sie später wieder zusammenzuführen, stoßen die traditionellen VCS an Grenzen.

Dezentraler Code

Von 2002 bis 2005 wandte sich Torvalds darum erst dem proprietären Bitkeeper und später der freien Entwicklung Git zu, die mehr Komfort beim Verwalten von Varianten bieten. Git unterscheidet sich von anderen VCS darin, dass es kein zentrales Repository vorhält, sondern dezentrale Kopien des Code erlaubt. Es unterstützt den Austausch zwischen ihnen in Form von Patches. So lässt sich die Änderungshistorie großer Teile des Linux-Quelltextes seit der Einführung von Git im Frühjahr 2005 verfolgen.

Der komprimierte Quelltext des Kernels kommt als knapp 60 MByte großes Archiv daher und enthält rund sieben Millionen Zeilen Sourcecode. Da diese Menge nur schwer überschaubar ist, teilen die Entwickler sie in so genannte Subsysteme auf, die jeweils für eine eigenständige Funktionalität, ein bestimmtes Gerät oder eine Plattform zuständig sind. Aktuell betreuen rund 100 Maintainer knapp 300 Subsysteme vom Netzwerkstack bis hin zu kleinen Gerätetreibern.

Waren viele dieser Maintainer und Entwickler früher nichts als Enthusiasten, bezahlen heute viele Unternehmen sie dafür, diese Rolle einzunehmen, das unterstrich Andrew Morton auf der Konferenz. Bei der Qualitätssicherung und beim Berichten von Fehlern überwiegen jedoch die unbezahlten Freiwilligen.

Offizieller Kernel

Die meisten Maintainer setzen ebenfalls wie Morton und Torvalds Git ein. Die zentrale Frage für Entwickler und Maintainer lautet, wie der von ihnen geschriebene Code letztlich seinen Weg in die von Linus Torvalds gemanagten Versionen auf [http://kernel.org] findet.

Entwickler und Maintainer organisieren sich von Subsystem zu Subsystem individuell und testen ihren Code. Sie reichen die durchgeführten Änderungen in Form einer Serie von kleinen Änderungen (Patchsets) an Morton weiter. Der prüft, ob sich Konflikte mit anderen Subsystemen ergeben, und übernimmt die Patchsets schließlich in den von ihm betreuten »mm«-Tree in Git. Die Dauer dieses Prozesses schätzt Morton auf etwa zwei Monate (Abbildung 1).

Abbildung 1: Der Weg vom ersten Patch bis zur offiziellen Kernelrelease ist lang: Nachdem Entwickler Änderungen mit dem Maintainer abgestimmt haben, soll dieser ab sofort seine Patches in »linux-next« einreichen. Von dort gehen sie nach der Kontrolle durch Morton zu Linus Torvalds. Er nimmt sie innerhalb eines Patch-Window in die nächste Kernelversion auf.

Nachdem er eine als stabil gekennzeichnete Version 2.6.x veröffentlicht hat, öffnet Linus Torvalds ein so genanntes Merge Window. In dieser Zeit leitet Andrew Morton die gesammelten Änderungen an Torvalds weiter. Nach zwei Wochen schließt dieser das Fenster wieder und veröffentlicht die Version 2.6.x-rc1. Entwickler und Tester prüfen das Ergebnis und sorgen im Zwei-Wochen-Rhythmus für weitere Release Candidates. Ungefähr zwei Monate nach dem Öffnen des Merge Window ist die nächste stabile Version fertig und der Prozess wiederholt sich.

Die Linux-Entwickler betonen immer wieder die Vorzüge dieses Verfahrens gegenüber der früheren Parallelentwicklung von experimentellem und produktionsreifem Code: Anwender kämen so schneller in den Genuss eines ausführlich getesteten Kernels. Es habe sich gezeigt, dass Benutzer zu wenig motiviert sind, um experimentellen Code zu testen, erklärt Morton. Auch verweist er auf die Distributionshersteller, die eine weitere Stufe der Qualitätssicherung umsetzen, indem sie durch eigene Entwickler Patches pflegen und so aus der Technologie Linux ein Produkt machen.

Das Verfahren hat sich bewährt, es bedeutet aber eine Menge Aufwand für Morton. Da 85 Prozent der Änderungen ohnehin erfahrene Maintainer in den Kernel einreichen, plant Morton nun eine weitere Zwischeninstanz einzuführen. Er kündigte an, dass der Australier Stephen Rothwell künftig einen Git-Tree namens »linux-next« pflegen werde, in dem Rothwell schon getestete Änderungen aus bekannten Subsystemen zusammenführt.

Online
Linux-Magazin Online zeigt auf [https://www.linux-magazin.de]ausführliche Mitschnitte der Video-Interviews mit Andrew Morton und anderen Kernelentwicklern. Sie finden sich unter dem Suchwort »video kernel«.

Leichtere Arbeit

Morton selbst will sich stärker um die restlichen 15 Prozent individuellen Patches kümmern. Diesen Plan haben einige Verantwortliche kritisiert, etwa der Maintainer der ARM-Plattform, Russell King. Er wies darauf hin, dass »linux-next« gelegentlich inkonsistent sei. Dennoch setzten sich sowohl Greg Kroah-Hartman als auch Morton für diesen Weg ein.

Zwar sieht er den Linux-Kern in einem guten Zustand, aber es bestünde nach wie vor hoher Bedarf an Tests, da sich die Hardware rasant ändere und in vielen Variationen auftrete. Alles können die Entwickler selbst gar nicht testen, dazu sei die Anzahl an CPU-Typen, Bios-Implementationen und Geräten einfach zu groß: Einige Probleme entstünden schlicht aus Fehlern in der Hardware.

Auf den Ton angesprochen, der auf den Listen herrscht, verweist Morton darauf, dass dieser informell und von “Entwickler zu Entwickler” sei, daher manchmal auch etwas rau. Trotzdem sagte er: “We’re not complete animals”, zu Deutsch etwa: Wir sind aber keine wilden Tiere.

Interview mit Andrew Morton
Mit dem bei Google angestellten Kernelentwickler sprach Linux-Magazin-Redakteur Nils Magnus im April in Hannover am Rande der Konferenz “Open Source Meets Industry”. Linux-Magazin: Andrew, wie stabil ist der Linux-Kernel 2.6? Andrew Morton: Ziemlich unstabil, wenn man bedenkt, mit welcher Geschwindigkeit wir Änderungen einbauen. Aber die Weise, wie wir das tun, ja, das hat sich stabilisiert. Wir stehen ja im engen Kontakt mit unseren “Kunden”, den Distributionen und den Leuten, die den Code direkt von Kernel.org nehmen, etwa Embedded-Hersteller. Sollten wir jemals etwas ändern, sprechen wir erst mit ihnen.Unzufrieden sind einige von uns damit, dass wir manchmal dem Kernel mehr Fehler zufügen, als unvermeidlich ist. Wir haben schon darüber nachgedacht, mal eine Bugfix-only-Release herauszubringen. Das machen wir vielleicht irgendwann. Das wäre aber nur eine kleine Anpassung des Prozesses, da er bislang recht gut funktioniert. Linux-Magazin: Wie siehst Du die Qualitätssicherung bei Linux? Sollte sich hier noch etwas tun? Morton: Wir sind sehr abhängig von den vielen Anwendern in aller Welt, weil wir selbst gar nicht so viele Maschinen haben, um alle Kombinationen zu testen. Aber Linux hat bereits eine vielschichtige Qualitätssicherung: Wir testen einiges selbst, weitere Tests führen die Distributoren oder weitere Dienstleister durch. So kann jeder wählen, wie viel Stabilität versus Features er haben möchte. Linux-Magazin: Wünscht Du Dir manchmal mehr Entwickler, die an Linux arbeiten? Morton: Wir können immer mehr Entwickler gebrauchen: Es gibt einige Bereiche im Kernel, die niemand betreut. Wir versuchen alle unser Bestes, aber vieles bleibt an mir hängen. Wenn sich also jemand auf, sagen wir, serielle oder PCMCIA-Treiber spezialisieren möchte, hätte ich ihn gerne an Bord. Linux-Magazin: Braucht Linux mehr Tester oder Hardware? Morton: Testen selbst ist relativ einfach. Komplizierter ist es, einen konkreten Fehler zu lokalisieren. Das kann viel Zeit in Anspruch nehmen. Hardware hingegen brauchen wir nicht – schon weil wir niemand hätten, um sie zu betreiben. Linux-Magazin: Wie ist die Unterstützung durch die einzelnen Hardwarehersteller? Morton: Mittlerweile klappt das gut. Es gibt ein paar Ausnahmen: Da ist Nvidia, da gibt es ein paar Hersteller von WLAN-Chipsätzen. Insgesamt ist Hilfe von den Ingenieuren der Hersteller natürlich toll, aber ich hätte zumindest gerne vernünftige Dokumentationen. Linux-Magazin: Wie kann Linux ohne einen experimentellen Codezweig neue Features einbauen? Morton: Ich denke, dass wir im 2.6er Kernel gezeigt haben, dass wir auch größere Änderungen einbauen können, etwa die 4-Level-Pagetables. Das hat die Stabilität nicht beeinträchtigt. Aktuell kann ich mir keine Änderung vorstellen, die wir mit diesem Modell nicht abbilden können – vielleicht irre ich mich hier, wir werden sehen. Linux-Magazin: Wie lange machst Du diesen Job jetzt eigentlich? Morton: Linus fragte mich 2002, ob ich der Maintainer für 2.6 werden wolle. Damals hatten wir alle noch den Plan, einen 2.7er Zweig zu eröffnen, wozu es ja aber nicht kam – (lachend) seither sitzen wir beide mehr oder weniger auf dem gleichen Posten.

Interview mit Andrew
Morton

Mit dem bei Google angestellten Kernelentwickler sprach Linux-Magazin-Redakteur Nils Magnus im April in Hannover am Rande der Konferenz “Open Source Meets Industry”.

Linux-Magazin: Andrew, wie stabil ist der Linux-Kernel 2.6?

Andrew Morton: Ziemlich unstabil, wenn man bedenkt, mit welcher Geschwindigkeit wir Änderungen einbauen. Aber die Weise, wie wir das tun, ja, das hat sich stabilisiert. Wir stehen ja im engen Kontakt mit unseren “Kunden”, den Distributionen und den Leuten, die den Code direkt von Kernel.org nehmen, etwa Embedded-Hersteller. Sollten wir jemals etwas ändern, sprechen wir erst mit ihnen.Unzufrieden sind einige von uns damit, dass wir manchmal dem Kernel mehr Fehler zufügen, als unvermeidlich ist. Wir haben schon darüber nachgedacht, mal eine Bugfix-only-Release herauszubringen. Das machen wir vielleicht irgendwann. Das wäre aber nur eine kleine Anpassung des Prozesses, da er bislang recht gut funktioniert.

Linux-Magazin: Wie siehst Du die Qualitätssicherung bei Linux? Sollte sich hier noch etwas tun?

Morton: Wir sind sehr abhängig von den vielen Anwendern in aller Welt, weil wir selbst gar nicht so viele Maschinen haben, um alle Kombinationen zu testen. Aber Linux hat bereits eine vielschichtige Qualitätssicherung: Wir testen einiges selbst, weitere Tests führen die Distributoren oder weitere Dienstleister durch. So kann jeder wählen, wie viel Stabilität versus Features er haben möchte.

Linux-Magazin: Wünscht Du Dir manchmal mehr Entwickler, die an Linux arbeiten?

Morton: Wir können immer mehr Entwickler gebrauchen: Es gibt einige Bereiche im Kernel, die niemand betreut. Wir versuchen alle unser Bestes, aber vieles bleibt an mir hängen. Wenn sich also jemand auf, sagen wir, serielle oder PCMCIA-Treiber spezialisieren möchte, hätte ich ihn gerne an Bord.

Linux-Magazin: Braucht Linux mehr Tester oder Hardware?

Morton: Testen selbst ist relativ einfach. Komplizierter ist es, einen konkreten Fehler zu lokalisieren. Das kann viel Zeit in Anspruch nehmen. Hardware hingegen brauchen wir nicht – schon weil wir niemand hätten, um sie zu betreiben.

Linux-Magazin: Wie ist die Unterstützung durch die einzelnen Hardwarehersteller?

Morton: Mittlerweile klappt das gut. Es gibt ein paar Ausnahmen: Da ist Nvidia, da gibt es ein paar Hersteller von WLAN-Chipsätzen. Insgesamt ist Hilfe von den Ingenieuren der Hersteller natürlich toll, aber ich hätte zumindest gerne vernünftige Dokumentationen.

Linux-Magazin: Wie kann Linux ohne einen experimentellen Codezweig neue Features einbauen?

Morton: Ich denke, dass wir im 2.6er Kernel gezeigt haben, dass wir auch größere Änderungen einbauen können, etwa die 4-Level-Pagetables. Das hat die Stabilität nicht beeinträchtigt. Aktuell kann ich mir keine Änderung vorstellen, die wir mit diesem Modell nicht abbilden können – vielleicht irre ich mich hier, wir werden sehen.

Linux-Magazin: Wie lange machst Du diesen Job jetzt eigentlich?

Morton: Linus fragte mich 2002, ob ich der Maintainer für 2.6 werden wolle. Damals hatten wir alle noch den Plan, einen 2.7er Zweig zu eröffnen, wozu es ja aber nicht kam – (lachend) seither sitzen wir beide mehr oder weniger auf dem gleichen Posten.