Linus Torvalds: Quellcode lese ich nicht mehr
In einem Interview äußert sich der Linux-Erfinder zu wichtigen Ereignissen der Kernel-Entwicklung und seiner Rolle als deren Lenker. Er geht zudem auf die Bedeutung von Tablets, Clouds und Google für Linux-Kernel ein. Mit Git und einer Tauchsoftware hat Torvalds zudem Spaß an der Programmierung von Userland-Software gefunden – letztlich kehrt er aber immer wieder zur Kernel-Entwicklung zurück.
- Glyn Moody
Das Interview wurde auf der LinuxCon Europe 2012 geführt. Die englische Originalversion findet sich auf The H.
Ich hatte das Glück, bereits recht früh in der Geschichte von Linux zum ersten Mal ein Interview mit Linus Torvalds führen zu dürfen. Das war 1996, als der Schöpfer des freien Betriebssystems noch in Helsinki gelebt hat (das Ergebnis ist in einem Wired-Artikel nachzulesen). Es war eine wichtige Zeit für den jungen Finnen – sowohl auf der persönlichen Ebene (sein erstes Kind wurde in dieser Zeit geboren) als auch im Hinblick auf seine Karriere. Er war gerade dabei, zum Chiphersteller Transmeta zu wechseln. Die Stelle machte ihn letztendlich nicht glücklich, aber sie war für Torvalds der Anlass, nach Amerika zu ziehen, wo er noch heute lebt.
Nach Europa kommt Torvalds eher selten. Darum nutzte ich die Gelegenheit zu einem Interview, als er diesen Monat für ein Podiumsgespräch in Barcelona auf der LinuxCon Europe 2012 war. In diesem zweiten Interview sprach ich mit ihm über die für den Linux-Kernel und die Kernel-Community entscheidenden Ereignisse seit unserem ersten Austausch.
Glyn Moody: Beim Rückblick auf die letzten fünfzehn Jahre: Was sind da in deinen Augen die wichtigsten Ereignisse in der Kernelentwicklung gewesen?
Linus Torvalds: Was ich persönlich für sehr wichtig halte, sind die ganzen Schritte, die wir über die Jahre in Sachen Skalierbarkeit gemacht haben. Lief Linux anfangs ganz gut auf Systemen mit 2 bis 4 Prozessoren, sind wir jetzt so weit, dass es im Prinzip auch für Systeme mit 4000 CPUs geeignet ist. Es skaliert vielleicht nicht perfekt, aber in den meisten Fällen ist dann nicht der Kernel der Flaschenhals. Bei einer einigermaßen vernünftigen Auslastung skalieren wir eigentlich ziemlich gut. Das hat aber eine Menge Arbeit gekostet.
Insbesondere SGI hat, wenn es um die Skalierbarkeit auf mehr als einige Hundert CPUs geht, viel geleistet. Ihre ersten Patches konnten wir nicht in den Kernel aufnehmen. Es gab einfach keine Möglichkeit, ihren Code auf normalen PCs zum Laufen zu bringen. Dafür setzte er einfach zu viel Infrastruktur für den Betrieb auf Systemen mit mehreren Tausend CPUs voraus. Das einzurichten war viel zu aufwendig, wenn man nur wenige Prozessoren hatte.
Ich habe lange befürchtet, dass der High-Performance-Kernel etwas für richtig große Systeme bleibt und dass der Quellcode vom Standardkernel getrennt bleibt. Viele Menschen haben viel Zeit darauf verwendet, die Codebasis so zu gestalten, dass man bei der Kompilierung die volle Flexibilität hat. Wenn man einen Kernel für ein System mit 4000 Prozessoren braucht, wird der entsprechende Code generiert. Wenn man hingegen einen Kernel für nur zwei CPUs benötigt, wird dieser aus genau dem gleichen Quellcode erstellt.
In der Rückschau geht es hier um eine wirklich wichtige Sache, denn diese Arbeiten haben den Quellcode wesentlich besser gemacht. SGI und andere haben den Code nicht nur vereinheitlicht, sondern auch an vielen Stellen bereinigt. Hat ein bestimmter Abschnitt zum Beispiel nicht mit Systemen mit hundert CPUs funktioniert, wurde er so angepasst, dass es ging. Letztendlich ist der Kernel dadurch viel wartungsfreundlicher geworden. Auf dem Desktop sind Systeme mit 8 oder 16 Kernen heute fast Standard. Früher war es schwierig, auf 8 CPUs zu skalieren; heutzutage ist das ein Kinderspiel.
Aber auch am ganz anderen Ende der Skala haben wir viel erreicht. Für die Smartphone-Leute, vor allem die auf der ARM-Seite, war Strom sparen zum Beispiel ein so wichtiges Thema, dass sie unschöne Hacks entwickelten, damit ihre Systeme möglichst lange Laufzeiten erreichten. Mit Powermanagement im Allgemeinen haben wir uns beim Kernel jedoch viele Jahre beschäftigt. Dabei ging es im Prinzip um die gleichen Themen. Statt uns aber auf gerätespezifische Hacks zu konzentrieren, wie es die ARM-Leute taten, bemühten wir uns um eine Lösung, die das ganze Spektrum abdeckt. Die zu entwickeln hat uns bestimmt fünf Jahre Zeit gekostet.
In vielen Fällen kann man die Unterstützung für ein bestimmtes Gerät hinzufügen, ohne dass sich dies auf den Rest des Kernels auswirkt. Beim Powermanagement jedoch sind gleich alle Gerätetreiber, die wir haben, betroffen – und das sind mehrere Tausende. Powermanagement beeinflusst Kernfunktionalität wie das Abschalten von CPUs; es wirkt sich auf Scheduler aus, auf die Speicherverwaltung, kurz: auf alles.
Und nicht nur wirkt es sich auf alles andere aus, Powermanagement hat auch das Potenzial, Funktionalität zu zerstören. Das macht es zu einem sehr schwierigen Thema. Oft mussten wir für zwei Schritte vorwärts einen Schritt rückwärts machen, weil eine echte Verbesserung etwas anderes kaputt gemacht hat. Deshalb mussten wir dann zurückrudern, um die Systeme, die dadurch nicht mehr funktionierten, wieder in Ordnung zu bringen.
Realistisch betrachtet besteht in jedem Release der Großteil der Arbeit aus Arbeit an Treibern. Eigentlich ist das langweilig, denn es gibt nichts grundlegend interessantes an Gerätetreibern. Sie bieten schlicht und ergreifend Unterstützung für einen bestimmten Chip oder eine bestimmte Hardwarekomponente. Aber genau das ist das täglich Brot des Kernels. Mehr als die Hälfte des Kernels besteht aus Treibern. All diese spannenden neuen Dinge, mit denen wir uns beschäftigen, verblassen letztendlich neben der ganzen Arbeit, die wir damit verbringen, neue Hardware zu unterstützen.
