Interview: Linux wird immer fehlerhafter

Golem.de im Gespräch mit Kernel-Maintainer Andrew Morton. Nach Meinung von Kernel-Maintainer Andrew Morton wird der Linux-Kernel 2.6.x immer fehlerhafter. Dem pflichten auch Linus Torvalds und andere Linux-Entwickler bei. Einen extra Entwicklungs-Kernel werde es dennoch nicht geben, so Morton gegenüber Golem.de. Den Kernel sieht Morton mittlerweile als Produkt an, das für Kunden wie die Distributoren entwickelt werde. Mit einer Neulizenzierung unter der GPL v3 beschäftigen sich die Entwickler nach Mortons Aussage nicht weiter, wohl aber mit der Integration von Virtualisierungslösungen.

9. Mai 2006 um 12:07 Uhr / Julius Stiebert

Affiliate-Hinweis

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

In seiner Keynote auf dem LinuxTag 2006 erklärte Linux-Maintainer Andrew Morton das Entwicklungsmodell des Kernels. Er arbeitet zusammen mit Linus Torvalds an den OSDL am Linux-Kernel und entscheidet letztendlich, welcher Code seinen Weg in den Kernel findet oder nicht.

Rund 9.200 Zeilen Code ändern sich laut Mortons Statistik täglich, dabei werde der Kernel allerdings immer fehlerhafter. Es sehe so aus, als würden neue Fehler schneller in den Kernel gelangen als die Entwickler alte bereinigen könnten. Dies geschehe auch durch den Verzicht auf eine Entwicklerversion, sagte Morton im Gespräch mit Golem.de. Doch das Entwicklungsmodell des Kernels 2.5 habe so gut funktioniert, dass man es beibehalten habe.

Einen 2.7er-Kernel werde es definitiv nicht geben, dafür seien die Bugfix-Veröffentlichungen mit Versionsnummern wie 2.6.x.y.z da. "Die Bugfixes sind ein einfacher Service für unsere Nutzer, für uns sind sie eigentlich Zeitverschwendung. Obwohl, es gibt einen Grund für diese Veröffentlichungen: Sie bringen uns mehr Tester, die neue Fehler finden", so Morton. Bei der Einführung eines reinen Entwicklungs-Kernels hingegen würde keiner mehr an der stabilen Serie arbeiten wollen, sagte Morton weiter.

"Wir müssen die Entwicklung über kurz oder lang allerdings wieder verlangsamen. Sonst werden wir nie Herr über die Fehler, die definitiv auf Grund der vielen neuen Funktionen in den Kernel gelangen", sagte Morton. Die Lösung für das Problem der zunehmenden Fehler sei einfach: "Wir müssen vorsichtiger sein und mehr Zeit für die Fehlerbehebung aufbringen." Ob es eine neue, stabile Kernel-Serie auf Basis von Kernel 2.6.16 brauche, wollte Morton nicht beantworten. Er meint, dass Adrian Bunk seinen angekündigten Versuch einfach starten soll, dann würde sich schon zeigen, ob die Nutzer die neuen Versionen annehmen.

Neue Funktionen werden laut Morton in zwei Modellen entwickelt: In Anlehnung an Eric Raymond würden bei der Basarmethode kleinere Neuerungen an die Maintainer weitergereicht, wohingegen bei der Kathedralenmethode neue Funktionen isoliert entwickelt werden. Ein Beispiel dafür sind die Virtualisierungslösungen, die in den Kernel drängen. Doch auch das schon lange auf die Aufnahme in den Kernel wartende Dateisystem Reiser4 entstand auf diesem Weg.

"Es gibt Probleme mit Reiser4 und jemand müsste sich eingehend damit beschäftigen. Den Code prüfen und anpassen. Es ist ein schwieriges Problem, denn die Reiser-Entwickler haben viel Arbeit in ihr Dateisystem gesteckt", sagte Morton. Die Auseinandersetzungen, die es zwischen Hans Reiser und den Kernel-Entwicklern gab, kommentierte Morton einfach mit "Müll". Persönliche Probleme dürften nicht zählen, die Technik müsse im Vordergrund stehen. Daher solle man die Auseinandersetzungen vergessen und sich auf die Technik konzentrieren, um Reiser4 endlich in den offiziellen Kernel zu bekommen.

Der Hypervisor Xen – dessen Entwickler schon länger an der Aufnahme in den offiziellen Kernel feilen – wird nach Mortons Einschätzung auf jeden Fall innerhalb des nächsten Jahres in den Kernel aufgenommen. Die Xen- sowie die Kernel-Entwickler müssten den großen Code-Brocken allerdings eingehend prüfen. "Ich habe schon vor einem Jahr erwartet, dass Xen aufgenommen wird", so Morton. Dass es nicht geklappt habe, liege nicht an den Kernel-Entwicklern, sondern am Xen-Team: "Sie haben uns keinen Code geschickt und nicht genügend Ressourcen in die Anpassung gesteckt." Die Situation habe sich aber bisher nicht wesentlich geändert: "Es gab Diskussionen, ob Xen als Architektur oder Sub-Architektur integriert wird. Die sind noch nicht abgeschlossen." Die Tatsache, dass Red Hat intensiv an der Xen-Integration arbeitet, habe daran auch nichts geändert.

Laut Morton könne trotzdem ohne Probleme eine zweite Virtualisierungslösung in den Kernel gelangen. So arbeitet beispielsweise auch das OpenVZ-Projekt daran, den eigenen Quelltext fit für den offiziellen Kernel zu machen. "Ich bin mir nicht sicher, ob es sinnvoll ist, mehrere Virtualisierungsansätze im Kernel zu haben. Überhaupt wurde diese Frage noch nicht angemessen beantwortet. Doch wenn wir eine gute Schnittstelle für einen Hypervisor im Kernel haben, sollte diese auch andere Hypervisor unterstützen." Neben x86 sollten auch andere Architekturen virtualisiert werden. Auf dem Kernel Summit im Juli 2006 in Ottawa möchte Morton entsprechende Gespräche führen, um die Integration solcher Techniken voranzutreiben.

Angst vor fehlenden Maintainern des Virtualisierungscodes hat Morton jedoch nicht. Gerade Xen muss sich häufig dem Vorwurf stellen, dass die Entwickler viel Zeit auf neue Funktionen verwenden, anstatt ihre Lösung zu stabilisieren. "Die Distributoren wie Red Hat und Suse liefern Xen aus und bieten Support dafür an. Also denke ich, dass sie alles daran setzen, den Code zu stabilisieren."

Der kürzlich von Devicescape veröffentlichte WLAN-Stack für Linux wird laut Morton schon bald seinen Weg in den Kernel finden. "Ich hoffe, dass es unsere WLAN-Unterstützung verbessert – andernfalls würden wir es nicht aufnehmen", so Morton weiter. "So lange keine bestehenden Teile des Kernels zerstört werden, kann das nur gut für uns sein."

Welche Funktionen in absehbarer Zeit in den Kernel gelangen, konnte Morton nicht sagen: "Das entscheiden die Entwickler, die an Funktionen arbeiten. Ich kann nur 'nein' zu einer Funktion sagen". Ausschlaggebend seien dabei vor allem die großen Firmen wie Intel, IBM, HP, Red Hat und Novell, die ihren Entwicklern vorgeben, woran sie arbeiten sollen. "Ich habe auch keine persönliche Wunschliste. Alles, was mich interessiert, sind die Fehler."

Ausschließlich als Binärmodul verfügbare Linux-Treiber sorgten in letzter Zeit immer öfter für Diskussionen. Sowohl unter den Entwicklern als auch zwischen den Kernel-Entwicklern und Firmen wie AVM. Nach einem Patch von Greg Kroah-Hartman akzeptierte der Kernel auf einmal nur noch GPL-Treiber, nach kurzer Auseinandersetzung flog die Änderung jedoch wieder aus dem Code, so dass Binärtreiber wie zuvor funktionieren. "Wir sollten die Unterstüzung für proprietäre Treiber niemals ohne Warnung entfernen." Die Kernel-Entwickler mögen laut Morton zwar grundsätzlich keine Binärtreiber und möchten die Firmen dazu bringen, ihre Module unter der GPL zu veröffentlichen. Eine einschneidende Änderung müssten sie jedoch etwa sechs Monate vorher ankündigen. Nur so könnten die Betroffenen die Schnittstellenänderung verstehen und frühzeitig darauf reagieren.

"Wir werden es Binärtreibern langsam immer schwerer machen. Die Firmen sollen endlich aufhören, ihre Spiele zu spielen", erklärte Morton. Es gebe aber definitv Gebiete, in denen dies unrealistisch sei, beispielsweise bei Grafikkartentreibern. "Die Situation ist schwierig und wir wollen dies auch nicht übermäßig diskutieren. Doch sollte es eine Verbesserung für den Kernel geben, durch die wir die Unterstützung für Binärtreiber entfernen müssen, dann machen wir das", sagte Morton weiter. Um zusätzliche Probleme zu vermeiden, solle dies aber auf jeden Fall nicht ohne Vorwarnung ablaufen. "Die Nutzer sind in jedem Fall die klaren Verlierer."

Während die Free Software Foundation (FSF) noch an der neuen Version der GNU General Public License arbeitet, die bisher nur in einem ersten Entwurf existert, stellte Linus Torvalds bereits klar, dass der Kernel weiterhin ausschließlich unter der GPL v2 lizenziert bleibe. Durch den Auschluss der Kompatibilität mit neueren Versionen würde der Kernel so inkompatibel zur GPL v3. "Tausende Entwickler haben Code zum Kernel beigetragen und diesen unter der GPL 2 lizenziert. Wir haben kein Recht, dies zu ändern", sagte Morton. "Außerdem denke ich, dass Linus der FSF nicht sonderlich vertraut. Ich selbst denke, sie benutzen ihre Lizenz, um politische Spielchen zu spielen. Sie nutzen die GPL, um ihre Ansichten über Digital Rights Management und Ähnliches durchzusetzen und anderen aufzudrängen", so Morton weiter. Ein wirkliches Problem sieht er nicht, wenn die alte Lizenz beibehalten wird: "Wer sich nicht wohlfühlt, wenn er seinen Code für einen unter der GPL v2 lizenzierten Kernel schreibt, soll ihn eben nicht schreiben.". Der Maintainer-Mangel wird durch diese sture Haltung allerdings auch nicht gelöst.

Nachtrag:Mittlerweile haben sich auch Linus Torvalds und andere Kernel-Entwickler zu dem Thema geäußert: Gegenüber Linux.com bestätigte Torvalds den von Morton formulierten Eindruck. Wie auch Morton ist Torvalds der Ansicht, dass man die Entwicklung etwas verlangsamen müsse. Ein Schritt könne beispielsweise sein, mit 2.6.18 erst einmal keine neuen Funktionen in den Kernel aufzunehmen. Allerdings werde der Kernel 2.6.16 immer weiter stabilisiert und viele Distributoren würden auf ihn zurückgreifen. Somit könne auch dieser Kernel ein Ausgangspunkt für eine stabile Version sein.

Kernel-Entwickler Adrian Bunk hatte bereits im Dezember 2005 angekündigt, auf Basis von 2.6.16 eine neue Kernel-Serie zu starten. In diese sollten nur Sicherheits- und Treiberupdates einfließen, während neue Funktionen außen vor bleiben müssten. Die 2.6.16-Serie soll laut Bunk vor allem Nutzer ansprechen, die derzeit noch auf Kernel 2.4 setzen und sich eine stabile 2.6er-Serie mit Sicherheitsupdates, aber ohne Fehler wünschen.

Auch Dave Jones, der bei Red Hat am Kernel arbeitet, teilt Mortons Auffassung, wie er in seinem Blog schreibt. Fehler können seiner Ansicht nach nicht schnell genug behoben werden, da die Berichte die Maintainer nicht schnell genug erreichen, wofür er das Fehlerberichtswerkzeug Bugzilla verantwortlich macht. Jones merkt aber auch an, dass trotz zunehmender Fehler – die er auch auf den Mailinglisten anderer Distributionen beobachtet – weniger Fehler mit Quelltextanalysewerkzeugen wie Coverity gefunden würden. Demnach nimmt die Qualität des Kernel-Quellcodes also durchaus zu.