Seite 6: Diskussionen

Inhaltsverzeichnis

Was während der 2.6.27-Entwicklung geschah

Entwicklungslinien des Linux-Kernels Die Kernel-Hacker entwickeln den Linux-Kernel im Rahmen der 2.6-Serie stetig weiter. Dabei scheuen sie auch nicht vor umfangreichen Änderungen zurück. Es wird daher auf absehbare Zeit keinen 2.7-Entwicklerzweig geben, aus dem irgendwann eine Linux-Version 2.8.0 oder 3.0.0 hervorgeht, so wie Linux 2.6.0 aus dem 2.5-Entwicklerzweig entstand; stattdessen pflegen die Entwickler mehrere Kernel-Serien für verschiedene Anwenderkreise parallel. Die Hauptentwicklungslinie stellen die Versionen mit drei durch Punkte getrennten Nummern (2.6.x, also etwa 2.6.26) dar. [...] Parallel zur Hauptentwicklung pflegen die Verwalter der Stable-Kernel-Serie die beiden jeweils neusten Versionen der Hauptentwicklungslinie weiter und kennzeichnen die Überarbeitungen durch eine zusätzliche Zahl (2.6.x.y, beispielsweise 2.6.24.10 oder 2.6.25.8). (...mehr...)

Zahlreiche andere während der 2.6.27-Entwicklung geführte Debatten sind für die weitere Entwicklung von Linux von Bedeutung. So bekräftigte Linus Torvalds in einer Diskussion auf der Linux-Kernel Mailing List (LKML), dass ihn nichts dazu bewegen könnte, zum alten Entwicklungsmodell mit einer "unstable-series" zurückzukehren. Das derzeitige Modell sei so viel besser, dass es nicht wert sei, über die Eröffnung einer 2.7-Serie überhaupt nachzudenken ("I'm not going back to the old model. The new model is so much better that it's not even worth entertaining as a theory to go back."). Im Rahmen dieser Diskussion ließ der Linux-Vater jedoch durchblicken, dass er über eine Anpassung des Nummerierungsschema nachdenkt und Versionsbezeichnungen wie Linux 2008.10 erwägt. Es war erwartet worden, dass darüber auf dem Mitte September abgehaltenen Kernel Summit 2008 diskutiert würde – in den Berichten von der Konferenz findet sich aber bislang keine Informationen, ob das Thema überhaupt zur Sprache kam.

Während der 2.6.27-Entwicklung bremste Torvalds indes einige Entwickler und forderte sie auf, sich in der zweiten Phase des Entwicklungszyklus gefälligst wie vorgesehen auf das Beseitigen von Fehlern zu konzentrieren; größere Änderungen sollten für die nächste Kernel-Version zurückgestellt werden. Wenn sich die Kernel-Hacker in Zukunft daran halten, könnte das die Entwicklungszeit neuer Linux-Versionen etwas reduzieren – zuletzt sind aus der ursprünglich für zirka sechs Wochen angesetzten Stabilisierungsphase meist eher neun oder mehr geworden, weil einige der Fehler in den während des Merge-Window eingepflegten Änderungen nur langsam korrigiert werden und größere, spät aufgenommene Änderungen teilweise neue Fehler auslösen.

Auf dem Kernel Summit waren die Kernel-Entwickler sogar kurz davor, eine Verkürzung des Entwicklungszyklus auf insgesamt sechs Wochen zu beschließen – letztendlich nahmen sie von der Idee dann doch wieder Abstand. Auch die Unterstützung von ISA-Hardware sowie anderer veralteter und kaum mehr gepflegter Code (beispielsweise Video4Linux der ersten Generation) soll bis auf Weiteres im Kernel verbleiben und nicht rausfliegen, wie es Alan Cox vor der Entwicklerkonferenz gefordert hatte. Weitere Informationen zu diesen und anderen auf dem Kernel Summit 2008 diskutierten Themen finden sich in zwei Kernel-Logs auf heise open, die die bekannt gewordenen Informationen vom ersten und zweiten Tag zusammenfassen.

Einstieg in die Kernel-Entwicklung

Im dem kürzlich von der Linux Foundation veröffentlichten Dokument "How to Participate in the Linux Community" erklärt LWN.net-Gründer und -Autor Jon Corbet zahlreiche Hintergründe im Kernel-Entwicklungsprozess. Dabei gibt er viele Tipps, wie man in die Kernel-Entwicklung einsteigt und dabei Anfängerfehler im Code und bei der Zusammenarbeit mit den etablierten Kernel-Hackern vermeidet. Das dürfte nicht nur Hobby-Programmierern eine große Hilfe beim Einstieg in die Linux-Kernel-Community sein, sondern soll insbesondere mit der Linux- und Open-Source-Entwicklung nicht vertrauten Unternehmen einen Einblick in den Entwicklungsprozess von Linux vermitteln. Das scheint auch mehr als überfällig, denn in der Vergangenheit strauchelten schon diverse Hardware-Hersteller und deren Treiber-Programmierer heftigst beim Versuch, in die Linux- und Open-Source-Entwicklung einzusteigen. Corbet und die Linux Foundation sind zudem nicht die einzigen, die sich dem Thema widmen: Andi Kleen hatte kürzlich in dem Vortrag "On submitting kernel patches" auf dem OLS 2008 eine ganz ähnliche, jedoch etwas kürzere Übersicht zum Thema gegeben.

Wie wichtig Linus Torvalds stabile Schnittellen für Userland-Anwendungen sind, zeigt eine während der 2.6.27-Entwicklung geführte Diskussion auf der LKML. Durch eine für 2.6.28 geplante Änderung arbeiteten die bisherigen Version des X.org-Touchtreibers synaptics nicht mehr korrekt; das war aber nicht Schuld des Kernels, sondern ein schwerer, bislang unentdeckter Fehler im Touchtreiber, der erst durch die Kernel-Änderung ans Tageslicht kam. Auf Drängen und unter Mithilfe von Torvalds haben die Kernel-Entwickler den auslösenden Kernel-Patch schließlich trickreich modifiziert, damit auch die bisherigen Versionen des Treibers mit zukünftigen Kernel-Versionen ungestört zusammenarbeiten.

Besser auf den Distributor vertrauen

Wer seine Kernel bislang selbst kompiliert und installiert, sollte gründlich darüber nachdenken, ob er diese Praxis in Zukunft beibehält oder nicht doch auf die vorkompilierten Kernel eines Distributors umsteigt. Die Kernel-Entwickler geben nach längeren Debatten um die früher nur sporadisch vorgenommene explizite Auszeichnung von Fixes für Sicherheitslücken bei der Freigabe neuer Kernel mittlerweile meist gar nicht mehr an, ob Patches auch Sicherheitslücken korrigieren. Vielmehr legen die Betreuer der Stable-Series Anwendern von Kernel.org-Kerneln in der Freigabe-Mail seit der Veröffentlichung von 2.6.25.13 in der Regel mit Worten wie "Any users of the 2.6.25 kernel series should upgrade to this version" ein Update auf die neu herausgegebenen Versionen nah. Details zu den Änderungen fänden sich im Git-Webinterface oder dem Changelog.

Schaut man dort genauer hin, findet man in manchen, aber eben nicht allen der mit diesen Worten angekündigten Versionen Korrekturen für Sicherheitslücken. Bei 2.6.25.13 etwa stolpert man über ein als CVE-2008-2750 diskutiertes Sicherheitsproblem im PPP-Code des Kernels, das Fedora, OpenSuse und Ubuntu bereits kurz zuvor über Kernel-Updates behoben hatten. Auf Sicherheit bedachte Anwender von selbstkompilierten Kerneln sollten daher am besten jede neue Version des jeweiligen Stable-Zweigs einspielen, was deutlich weniger Arbeit machen dürfte, als eine zeitaufwendige und praktisch nur von Sicherheitsexperten verlässlich durchführbare Suche nach Sicherheitskorrekturen in den Änderungen neuer Kernel-Versionen. Für das Gros der Anwender dürfte ohnehin ein vorkompilierter und vom Distributor gepflegter Kernel der verwendeten Linux-Distribution die eindeutig beste Wahl darstellen – zu einem solchen rieten auch so mache Kernel-Entwickler im Rahmen der erwähnten Diskussionen.