Gemeinschaft::Konferenzen
Linux-Kongress 2010 - Keynote von Jon Corbet
Kernel-Entwickler und LWN-Mitgründer Jon Corbet hat den Linux-Kongress 2010 mit einer Keynote über einige markante Fehlschläge in der Kernel-Entwicklung, und welche Lehren daraus zu ziehen sind, eröffnet.
Hans-Joachim Baader
Jon Corbet bei der Keynote
Jon Corbets Keynote mit dem Titel »Kernel development: how it goes wrong and why you should be a part of it anyway« zu früher Stunde fand zu früher Stunde vor knapp 100 interessierten Entwicklern statt. Seine erste Feststellung: Die
Kernelentwicklung ist ein Erfolg. Fünf neue Versionen im Jahr, jede mit rund 10000 Änderungen und jeweils 1000 Entwicklern sind dafür ein klares Indiz.
Also warum über Fehlschläge reden? Weil man daraus Lehren ziehen kann. Es ist nicht leicht, Zugang zur Kernel-Gemeinschaft zu finden, aber wenn man weiß, wie man die Entwickler zu nehmen hat, wird es einfacher. Es fehlt nicht an »Clowns« in der Gemeinschaft, wie Corbet sie nennt. Der Referent betonte jedoch, dass jeder namentlich erwähnte Entwickler dennoch seinen vollen Respekt hat.
Ein bekannter Fehlschlag war das Dateisystem Tux3 von Daniel Phillips: Die erste Ankündigung erfolgte am 23.7.2008, das letzte Commit in das Quellcode-Archiv war am 16.8.2009. Der Code gelangte nie in den Kernel. Im Nachhinein wäre es besser gewesen, den Code in den Kernel aufzunehmen, sobald das System mit Tux3 bootfähig war. Daraus kann man die allgemeingültige Lehre ziehen, zu Code, der nicht im Kernel ist, keine Features hinzuzufügen. Stattdessen sollte man an der Aufnahme in den Kernel arbeiten, sobald es möglich ist. Das bringt weitere Entwickler eher dazu, sich zu beteiligen.
Ein anderes Beispiel ist em28xx, ein v4l-Treiber. Markus Rechenberger, der Autor, entwickelte neue Version, deren Aufnahme in den Kernel abgelehnt wurde. Darauf zog er sich ganz aus der Kernelentwicklung zurück. Lektion: Einen Beitrag zum Kernel zu leisten, bedeutet, die Kontrolle über den Code zu »verlieren« (aufzugeben). Man muss akzeptieren, dass man nicht mehr alleine über den Code entscheidet.
Das IDE-Subsystem von Linux 2.5.x im Jahr 2002: Martin Dalecki schrieb Patches zum Aufräumen des Subsystems. Im März 2002 übernahm er das IDE-Subsystem und schrieb Patch um Patch, doch der Code war so fehlerhaft, dass er weitgehend unbenutzbar war. Im August nach Patch 115 wurde die gesamte Arbeit rückgängig gemacht und auf den Stand von Linux 2.4 zurückgesetzt. Lektion: Dinge, die man ändert, müssen funktionieren, und man muss aufmerksam auf Beschwerden eingehen.
Der Scheduler von Con Kolivas wirbelte seinerzeit viel Staub auf. Im März 2007 publizierte er die erste Version, Linus stellte daraufhin eine baldige Integration in Aussicht, doch dann zögerte er, irritiert durch negative Reaktionen anderer Nutzer. Ingo Molnar stellte im April den Complete Fair Scheduler CFS vor, der im Juli in Linux 2.6.23 aufgenommen wurde. Con Kolivas verließ die Kernel-Gemeinschaft im Streit. Lektionen: Eine Änderung muss eine Verbesserung für alle oder darf zumindest für niemand eine Verschlechterung darstellen. Einige Teile des Kernels sind schwer zu ändern. Man muss an der allgemeinen Diskussion teilnehmen, statt wie Kolivas nur in speziellen Listen präsent zu sein. Man sollte auf die Lösung eines Problems zielen, nicht auf die Aufnahme von spezifischem Code.
Das Schicksal des Dateisystems Reiser4 ist bekannt: Mehrere Versuche, es in den Kernel aufnehmen zu lassen, scheiterten, teilweise weil sie zum falschen Zeitpunkt gestartet wurden (kurz vor Freigabe von Linux 2.6). Probleme mit Reiser4, die letztlich die Integration verhinderten, waren u.a. nicht-POSIX-Verhalten, technische Probleme, schwer zu reproduzierende (»kreative«) Benchmarks, unkooperatives Verhalten und die Erinnerung an Reiserfs3, das nach der Kernel-Integration von Reiser nicht mehr gepflegt wurde. Lektion: Linux ist kein Forschungssystem, schlechte Implementationen sind nicht akzeptabel. Neue Ideen, wie sie Reiser4 zweifellos birgt, sind zwar willkommen, sie müssen aber in Übereinstimmung mit den Auffassungen der Kernel-Entwickler implementiert sein. Diese erinnern sich an frühere Aktionen eines Entwicklers und denken andererseits auch weit voraus.
Auch SystemTap kann nur als Fehlschlag bezeichnet werden. Im Oktober 2005 wurde es von Red Hat vorgestellt, zwei Jahre nachdem Sun DTrace in Solaris veröffentlicht hatte. Am 22.9.2009 erreichte es Version 1.0. Inzwischen wurde der Kernel um FTrace und Perf Events bereichert, SystemTap dagegen ist immer noch nicht integriert. Dies liegt auch daran, dass es selbst für talentierte Entwickler extrem schwer einzurichten und zu benutzen ist.
TALPA hat eine etwas andere Geschichte, da aus diesem Vorschlag schließlich noch etwas Brauchbares entstand. Vorgestellt wurde es im August 2008 mit dem Ziel, Einhängepunkte für Virenscanner zu schaffen. Dies wurde nie in den Kernel aufgenommen, da kein Entwickler den Sinn dieses Systems sah. In der Zwischenzeit wurde aber fanotify entwickelt, das nicht nur die Anforderungen der Antivirenindustrie erfüllt, sondern auch ein besserer Ersatz für inotify ist. Lektion: Patches müssen die Entwickler überzeugen, nicht die Manager.
Abschließend stellte Corbet die Frage, warum man trotzdem an der Entwicklung teilnehmen sollte. Die Antworten sind, dass es zum einen nicht so schwer ist, wie es scheint. Es macht Spass und ist etwas elitär, denn eindeutig ist nicht jeder zum Kernel-Entwickler berufen. Man erhält unweigerlich Job-Angebote, für viele auch ein gutes Argument. Sehr wichtig ist allerdings auch, dass man damit aktiv Einfluss auf die Entwicklung nimmt, so dass man den Kernel ein wenig in die Richtung lenken kann, die man will.
){kind=small}
