Architektur, Community & die Rolle von Linus

Glyn Moody: Was hat es für strukturelle Architekturänderungen zur Unterstützung neuer Hardware gegeben?

Linus Torvalds: Der USB-Stack wurde im Grunde bereits ein paar Mal neu geschrieben, weil es immer mal wieder neue Anwendungsfälle gab, bei denen wir feststellen mussten, dass wir sie im bisherigen Stack nicht bedacht hatten. USB 3.0 zum Beispiel braucht Unterstützung für neue Host-Controller und es stellt sich heraus, dass die Unterschiede so groß sind, dass es sinnvoll ist, den Core-Stack grundlegend zu überarbeiten, sodass er mit allen Versionen funktioniert. Und das gilt nicht nur für USB: Es gibt auch noch PCI, aus PCI wird PCIe und dann kommt auch noch Hot-Plug ins Spiel.

Das ist übrigens auch etwas, das Linux vom traditionellen Unix unterscheidet: Eine Unix-Workstation startet man und danach ändert sich das System nicht mehr – es werden keine Geräte hinzufügt. Heutzutage sind USB-Geräte eine Selbstverständlichkeit, aber das war nicht immer so. Hot-Plugging bedeutet eine strukturelle Änderung der Infrastruktur, die wir berücksichtigen mussten.

Glyn Moody: Wie sieht es mit der Kernel-Community aus? Wie hat sich diese verändert?

Linus Torvalds: In der Anfangszeit waren die Hierarchien viel flacher. Ich weiß nicht genau, wann es sich verändert hat, aber früher gab es neben mir vielleicht 50 Entwickler – und nur wenig Hierarchie. Heutzutage erreichen mich Patches, die vier verschiedene Ebenen passieren müssen. Alle drei Monate bringen wir eine neue Kernelversion heraus; daran sind jeweils etwa tausend Leute beteiligt. Die Hälfte all dieser Leute schickt uns im Prinzip nur eine einzige Codezeile für etwas, was nicht ganz so wichtig ist. Das ist die Art und Weise, wie viele Leute arbeiten. Manche tun nichts anderes und das ist in Ordnung. Aber wenn tausend verschiedene Leute Patches einreichen – vor allem wenn ein Teil von ihnen das "mal eben nebenher" macht – ist es für mich unmöglich, diese alle einzeln zu begutachten. Ich hätte einfach nicht die Zeit, mich mit den Leuten auszutauschen.

Manche Entwickler haben sich auf Treiber spezialisiert. Diese kennen wiederum andere Leute, die sich auf einen bestimmten Bereich spezialisiert haben und die Treiber schreiben oder Patches einreichen. Alle Patches gehen durch diese verschiedenen Schichten, bevor ich sie zu sehen bekomme. In seltenen Fällen sind vier verschiedene Leute daran beteiligt; zwei jedoch sind es recht häufig.

Glyn Moody: Was bedeutet das für deine Rolle?

Linus Torvalds: Der größte Unterschied zu früher ist, dass ich inzwischen selbst keinen Code mehr schreibe. Wenn ein Patch schon von zwei verschiedenen Leuten begutachtet wurde, könnte ich ihn mir auch noch anschauen und sagen: "Nein, schade um deine Mühe, aber den Code nehmen wir nicht" und Micro-Management mit allen Patches zu betreiben. Das möchte ich ehrlich gesagt nicht, und ich habe auch nicht die Kapazitäten dazu.

In der Praxis bedeutet das, dass ich auf das Urteil der Maintainer der großen Subsystemen vertraue. Das kann ich, weil ich bereits seit fünf, zehn oder fünfzehn Jahren mit ihnen zusammenarbeite. In den meisten Fällen schaue ich mir den Code nicht an. Die Subsystemverwalter berichten über die Änderungen und geben mir einen groben Überblick. Je nach Person können das fünf Textzeilen sein, in denen die Änderungen beschrieben werden, oder ich bekomme den Output von diffstat, der zum Beispiel zeigt, dass sich in dieser Datei 15 Zeilen geändert haben und in jener 25. Der Diffstat-Output kann auch einige hundert Zeilen umfassen, wenn sich einige hundert Dateien geändert haben. Den Code an sich sehe ich nicht. I sage nur: "Alles klar, die Änderungen passieren in diesen Dateien. Und ich vertraue dir, diese Änderungen durchzuführen." Und dann sage ich einfach: "Ich nehme den Code."

Glyn Moody: Wie sieht denn jetzt deine Rolle aus?

Linus Torvalds: Meine Hauptaufgabe ist das Managen anderer Leute. Nicht im herkömmlichen Sinne – ich bezahle ja niemanden –, aber ich muss mich auch nicht darum kümmern, dass Entwickler zum Beispiel Zugang zur richtigen Hardware haben. Ich schalte mich ein, wenn es Streit gibt oder Reibungen entstehen oder wenn Bugs auftreten.

Bugs treten immer wieder auf, aber oft wissen Leute nicht, an wen sie den Fehlerbericht schicken sollen. Deshalb schicken sie ihn an die Mailingliste des Linux-Kernels – aber niemand kann alles dort lesen. Wenn über die Mailingliste keine Hilfe kommt, fangen sie an oft an, mich mit Mails zu bombardieren: "Hey, meine Maschine funktioniert nicht mehr!" Weil ich selbst zwar den Code nicht gelesen habe, aber weiß, wer der richtige Ansprechpartner ist, bin ich oft der Dreh- und Angelpunkt für Bug-Reports und Änderungsaufforderungen. Das ist im Grunde alles, was ich tue. Tag ein, Tag aus lese ich E-Mails. Aber das ist prima, denn ich mag die Arbeit, auch wenn sie sich ziemlich von dem unterscheidet, was ich früher getan habe .