Die Woche: Beschränkter Blick auf den Kernel

Microsoft hat in der neuesten Auswertung der Linux Foundation nur knapp die Top 20 der Gruppen und Firmen verpasst, die am meisten zum Linux-Kernel beitragen. Das ist dem Unternehmen aber nur gelungen, weil es schlechten Code angeliefert und dann langsam verbessert hat.

In Pocket speichern vorlesen Druckansicht 31 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Thorsten Leemhuis

Zum vierten Mal hat die Linux Foundation eine Analyse der jüngst vorgenommenen Änderungen am Linux-Kernel veröffentlicht. Besondere Aufmerksamkeit wird den Teilen der Auswertung zuteil, die zeigen, welche Firma wie viel zu Linux beigetragen hat; gerade die Firmen, die auf den vorderen Plätzen stehen, brüsten sich gerne mit den Ergebnissen. Manchmal entsteht die Aufmerksamkeit in der Öffentlichkeit auch quasi von selbst, wenn in der Liste Firmen auftauchen, die man dort nicht erwartet: So geriet Microsoft in die Schlagzeilen, als eine ähnliche Auswertung von LWN.net ergab, ein Microsoft-Mitarbeiter führe die Liste der Entwickler an, die die meisten Änderungen zum Linux-Kernel 3.0 beigesteuert haben.

Wer diesen Zahlen irgendwo begegnet, sollte sich allerdings den Spruch "Traue keiner Statistik, die du nicht selbst gefälscht hast" in Erinnerung rufen. Denn auch wenn die Zahlenbasis solide ist – die Auswertung liefert lediglich eine Impression aus einem speziellen Blickwinkel, daher sollte man nicht allzu viel in diese Werte hinein interpretieren.

Ein anderes Beispiel wäre politisch vielleicht weniger heikel, aber am besten lässt sich das Problem tatsächlich an Microsoft illustrieren. Mit einem Prozent der zwischen Linux 2.6.36 und 3.2 vorgenommenen Änderungen hat das Unternehmen es in der neuesten Studie der Linux Foundation auf Platz 21 der Firmen und Gruppen geschafft, die zum Linux-Kernel beitragen.

Das ist der Arbeit an den Hyper-V-Treibern zu verdanken, durch die Linux möglichst gut als Gast unter der Virtualisierungslösung des Windows Server laufen soll. Microsoft hatte diese Treiber im Juli 2009 unter der GPLv2 freigegeben. Wenig später flossen sie in den Linux-Kernel 2.6.32 ein; allerdings nur in dessen Staging-Bereich, in dem die Kernel-Entwickler Treiber integrieren, die ihre Qualitätsansprüche nicht erfüllen.

Anders gesagt: Mit schlechtem Code sammelte Microsoft bei der Aufnahme die ersten Punkte. Und später auch viele weitere, denn wie es sich die Kernel-Entwickler wünschen, verbesserten die Microsoft-Programmierer die Staging-Treiber in kleinen, leicht nachvollziehbaren Schritten. Weil es halt immens viel zu verbessern gab, führte das zu 688 Änderungen (ein Prozent aller Commits) zwischen Linux 2.6.36 und 3.2. Der Code der Hyper-V-Treiber schrumpfte dabei um rund 60 Prozent; zudem sollen die Treiber nun bessere Performance liefern, stabiler arbeiten und nun eine solide Basis für weitere Verbesserungen sein, wie die Betreuer der Hyper-V-Treiber erläutern.

Letztlich haben die Hyper-V-Treiber so erst nach vielen Änderungen und mit Unterstützung durch erfahrene Kernel-Entwickler einen Qualitätsstandard erreicht, den die allermeisten Linux-Treiber schon bei der Aufnahme in den Kernel haben: Viele Firmen und Freizeit-Entwickler sind nämlich durchaus in der Lage, gleich ordentlichen Code anzuliefern. Die allermeisten Treiber landen daher gar nicht erst im Staging-Zweig.

Der Zwischenstopp im Staging-Bereich brachte die Entwickler von Microsoft in der Studie der Linux Foundation nach vorne, da den Auswertungen der Firmenbeiträge liegen die Commits zugrunde liegen – eine einzeilige Änderung an der Dokumentation wiegt genauso schwer wie ein Patch, der einen ordentlichen Treiber in den Kernel integriert und tausende neue Zeilen mitbringt. Jonathan Corbet, der auch an der Studie der Linux Foundation mitgearbeitet hat, erinnert an diese Problematik, wenn er seine Auswertungen zu neuen Kernel-Versionen auf LWN.net veröffentlicht (etwa zu 3.0, 3.1, 3.2 und 3.3): Neben den Tabellen, bei der die Zahl der Änderungen als Grundlage dient, veröffentlicht er nämlich auch solche, bei der die Zahl der geänderten Zeilen den Ausschlag gibt – dort kam Microsoft nicht so weit nach vorne.

Treiber, die gleich in guter Qualität in den Kernel einfließen, fallen also in Auswertungen wie jener der Linux Foundation nicht so stark ins Gewicht; vielmehr kommt man mit schlechtem Code und Verbessern dieses Codes nach vorn. Das ist nur eines von mehreren Problemen der Auswertung; so wie es aussieht, zählen nämlich auch Patches, die dem Linux-Kernel beiliegende proprietäre Firmware aktualisieren, oder Commits, die eine gerade erst vorgenommene Änderung wieder revidieren.

Daher noch einmal: Nicht zu viel in die Zahlen hineindeuten!

Wer nicht Linux unter den Virtualisierungslösungen des Windows Server betreibt, hat ohnehin rein gar nichts von dem einen Prozent der Änderungen, das Microsoft zwischen 2.6.36 und 3.2 beigesteuert hat. Manche Beiträge von Hobby-Entwicklern oder Firmen haben hingegen wichtige Änderungen gebracht, von denen viel mehr Linux-Anwender profitieren – aus der Analyse der Linux Foundation geht das überhaupt nicht hervor.

Fairerweise sei an dieser Stelle allerdings noch einmal betont, dass Microsoft nur als Beispiel herhalten musste – andere Staging-Treiber haben zu ähnlichen Verzerrungen geführt. Und an dieser Stelle auch noch ein Danke an Microsoft für die Einsicht, dass es für alle Beteiligten von Vorteil ist, wenn Treiber wie jene für Hyper-V ein ordentlicher Bestandteil des Linux-Kernels sind, wie es ab Linux 3.4 der Fall sein wird. Nicht alle Firmen sind schon so weit... (thl) (thl)