Kernel-Log: Studie liefert Hintergründe zur Entwicklung des Linux-Kernels

Die Linux Foundation hat eine aktualisierte Ausgabe ihrer Studie zum Thema "Who Writes Linux and Who Supports It" veröffentlicht , die Einblicke in die Entwicklung des Linux-Kernels bietet. Die neue Studie trägt den Titel "Linux Kernel Development – How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It" und analysiert ähnlich wie die erste und zweite Version unter anderem, welche Unternehmen die Kernel-Entwicklung vorantreiben, wie viele Programmierer Änderungen beisteuern und wie schnell der Kernel wächst.

Geschrieben wurde die Studie von Kernel-Entwickler und LWN.net-Chef Jonathan Corbet, dem bei Novell angestellten Kernel-Entwickler Greg Kroah-Hartman und Amanda McPherson von der Linux Foundation. Wie bei den beiden ersten Studien liegen auch der jetzigen die Daten seit Veröffentlichung der Kernel-Version 2.6.11 zugrunde – direkt danach hatte Torvalds zur Verwaltung der Kernel-Quellen auf das damals von ihm gestartete Quellcodeverwaltungssystem Git umgestellt. In einigen Bereichen der Studie haben sich die Autoren allerdings auf die Änderungen konzentriert, welche die Kernel-Entwickler zwischen der Freigabe der Versionen 2.6.30 und 2.6.35 vorgenommen haben – also dem Zeitraum zwischen der zweiten Studie und dem Schreiben der jetzt veröffentlichten. Wie schon zuvor nutzten die drei bei der Auswertung den "Git Data Miner" (gitdm).

Bild 1 von 9

Dritte Studie der Linux Foundation zur Kernel-Entwicklung (9 Bilder)

Linux Kernel Development

Treibende Kräfte

Seit Linux 2.6.11 haben Hobby-Entwickler knapp 19 Prozent der Änderungen vorgenommen. Bei Red Hat beschäftigte Entwickler folgen mit knapp 13 Prozent auf dem zweiten Platz vor Novell mit 7 Prozent; dahinter liegt IBM mit 6,9 Prozent vor der 6,4 Prozent starken Gruppe von Entwicklern, denen die Autoren keinen Arbeitgeber zuordnen konnte.

Red Hat und Hobby-Entwickler erreichen auch bei der Betrachtung der Änderungen die ersten Plätze, die in den 14 Monaten zwischen der Freigabe von 2.6.30 und 2.6.35 vorgenommen wurden. Intel konnte sich hier vor Novell schieben; die Autoren heben zudem hervor, dass Nokia, AMD, Texas Instruments und Samsung sich stärker eingebracht haben und dadurch in der Rangfolge nach oben gewandert sind.

Rechnet man die Gruppe der keinem Arbeitgeber zugeordneten Entwickler in beiden Aufstellungen zu den Hobby-Entwickler, dann zeigt sich, dass über 70 Prozent der Kernel-Hacker für ihre Arbeit am Kernel bezahlt werden.

Die Autoren haben sich auch angesehen, welche Entwickler denn den Code anderer Kernel-Hacker begutachten, bevor dieser in den Kernel einzieht – zumeist sind das die Betreuer von Subsystemen. Die meisten solcher Reviews hat im aktuellen Betrachtungszeiträume David S. Miller durchgeführt, der den Netzwerk-, IDE- und SPARC-Code betreut. Es folgt John W. Linville (WLAN) und Greg Kroah-Hartman (USB, Staging, Driver Core) vor Andrew Morton, der sich um alle Bereiche des Kernels kümmert. Fast 38 Prozent des Codes geht durch die Hände von Red-Hat-Entwicklern, Novell folgt mit gut 13 Prozent vor Intel mit etwas über 9 Prozent. In dieser Auswertung stellen die Hobby-Entwickler nur knapp 5 Prozent.

Die Studie macht auch Angaben zur Motivation dieser teilweise ganz verschieden positionierten Unternehmen. IBM, Intel, SGI, MIPS, Freescale, HP oder Fujitsu etwa liegt daran, dass Linux ordentlich auf ihrer Hardware läuft, damit diese attraktiver für den Linux-Einsatz sei und sich so besser verkauft. Linux-Distributoren wie Red Hat, Novell und Montavista wollen Linux so viele Fähigkeiten wie möglich beibringen; dazu arbeiten sie gemeinsam am Kernel, auch wenn sie im Markt Konkurrenten sind. Sony, Nokia oder Samsung hingegen setzen Linux auf ihren Produkten ein; ihre Beiträge zur Kernel-Entwicklung helfen, dass Linux auch in Zukunft eine solide Basis für den Einsatz in solchen Produkten darstelle.

[pagebreak Zahlenfülle, Ausgangsmaterial]

Zahlenfülle

Ungefähr 10.000 Änderungen fließen in jede neue Kernel-Version ein; seit 2005 haben über 6100 Programmierer von mehr als 600 verschiedene Unternehmen Patches zum Kernel beigesteuert. Die Zahl der pro Version integrierten Änderungen ist nach einem Peak bei 2.6.30 aber etwas zurückgegangen: Zurzeit fließen 5,2 Änderungen pro Stunde in den Kernel ein, etwas weniger als bei der 2009 publizierten Studie. Seitdem ist der Quellcode des Linux-Kernels um 1,5 Millionen Zeilen gewachsen.

Zu jeder Kernel-Version steuern typischerweise über 1000 Entwickler Änderungen bei, die Hauptarbeit leistet aber nur ein kleiner Teil von ihnen. Die zehn führenden Entwickler haben in den vergangenen fünfeinhalb Jahren rund 10 Prozent der Änderungen entwickelt; die Top 30 knapp 22 Prozent. Zu den aktivsten Entwickler zählen laut der Auswertung David S. Miller, Ingo Molnar und Al Viro; im Betrachtungszeitraum 2.6.30 bis 2.6.35 liegen Paul Mundt, Johannes Berg und Peter Zijlstra vorne. Die Autoren heben hervor, dass sich Torvalds nicht unter den Top 30 findet: Er sei aktiv und ein entscheidender Punkt im Entwicklungsprozess, seine Arbeit lasse sich aber nicht an geänderten Codezeilen messen. Ähnlich sei es auch mit einigen anderen "Senior Kernel Developers", die mehr Zeit in Review und Management investieren.

Speziell zu Anfang erläutert das Dokument auch einige der Arbeitsweisen, welche die Kernel-Hacker bei der Weiterentwicklung des Linux-Kernels nutzen. Dinge wie die Weiterentwicklung des Kernels im Rahmen der 2.6er-Serie mit einem zirka 3 Monaten langen Entwicklungszyklus dürften Lesern des Kernel-Logs aber genauso vertraut sein wie die Stable-Series und andere Kernel-Zweige.

Die Änderungen an den Stable-Kerneln haben sich die Autoren ebenfalls angesehen. Die meisten gab es bei der 32er-Serie, die genau wie zuvor 2.6.27 ein "Long Term Stable Release" ist, das über mehrere Jahre gepflegt wird. Die meisten anderen Kernel-Releases werden werden nur so lange unterstützt, bis sich die Nachfolgeversion etabliert und ohre Kinderkrankheiten abgelegt hat.

Ausgangsmaterial

Die Autoren weisen selbst darauf hin, dass etwa die Zuordnung von Entwicklern zu Unternehmen ungenau ist – etwa weil Entwickler den Arbeitgeber wechseln oder privates Engagement vom Büro aus erledigen. Sie schätzen die Zahlen aber als gut genug ein, um daraus Schlüsse ziehen zu können.

Auch an anderen Stellen dürfte die Art der Auswertung für einige Unschärfen sorgen, durch die einzelne Entwickler oder Unternehmen mit vergleichsweise wenig Arbeit recht gut abschneiden. So finden sich in den Kernel-Quellen unter anderem einige Firmware-Images als ASCII-Dateien. Sie sind teilweise recht groß und werden häufiger mal in einer Weise aktualisiert, wodurch die Änderung riesig wirken, selbst wenn nur Kleinigkeiten geändert wurden. Exemplarisch zeigen das zwei für 2.6.37 vorgenommene Commits: Der erste ist mehr als 1 Megabyte groß und entfernt zwei proprietäre Firmware-Dateien für Broadcom-Hardware und damit 22.000 Zeilen "Code"; ein 1,7 MByte großer Patch integrierte neue Versionen der Dateien und eine weiter Firmware, wodurch der Kernel wieder um 38.000 Zeilen wächst. Es war auf die Schnelle nicht feststellbar, in wie weit ähnliche Änderungen bei früheren Kernel-Versionen in der Studie eingingen.

Mitautor Greg Kroah-Hartman dürfte vermutlich ein klein wenig von der Verwaltung des Staging-Zweigs profitiert haben, in den Code einfließt, der den Qualitätsstandards der Kernel-Entwickler oder der Programmierer des Codes nicht genügt. Er braucht längst nicht so viel Arbeit in die Begutachtung dieses Codes zu stecken wie bei anderen von ihm betreuten Subsystemen. Zudem ist der Staging-Zweig stärker in Bewegung als der Rest des Kernels – schon mehrere Treiber flogen etwa nach einige Monate nach der Aufnahme wieder raus, weil sich niemand um sie gekümmert hat. Über verwandte WLAN-Treiber stieß ähnlicher oder identischer Code teilweise mehrfach zum Kernel, ging also auch mehrfach in die Auswertung ein.

Bei der Analyse der Anzahl der vorgenommenen Änderungen sind wiederum die Entwickler im Vorteil, die (wie es üblicherweise gewünscht ist) viele kleine Änderungen einsenden, statt mehrere großen. Solcher Schwächen und Unschärfen lassen sich aber nie komplett vermeiden; dennoch liefert die Studie viele gute Indikatoren und Einblicke, wenn man die Stellen hinterm Komma nicht zu genau nimmt.

[pagebreak Linux 2.6.37-rc4, Kernel-Log-Staccato]

Kernel-Versionsstatus

In der Nacht von Montag auf Dienstag hat Linus Torvalds die vierte Vorabversion von Linux 2.6.37 veröffentlicht. Hier habe er doppelt so viel Commits vorgenommen wie beim dritten RC, wie er in der Freigabe-Mail schreibt – verglichen mit den vierten Vorabversionen vorangegangener Kernel-Versionen sei die jetzige aber trotzdem recht klein und die Dinge liefen angemessen ruhig.

Ein Leser wies uns zudem auf eine in den RC4 eingeflossene Korrektur am Code für Unix-Sockets hin, die verhindert, dass ein Angriffsprogramm eine CPU voll belastet und alle Kernel-Internen Datei-Deskriptoren verbraucht und so das System zum Absturz bringt (1, 2). Die Änderung soll auch in die Kernel der Stable-Series einfließen; derzeit sind aber noch keine neuen Stable-Versionen in Sicht.

Kernel-Log-Staccato

Kernel

• Wer sich schon immer mal den Quellcode des Kernels vorlesen lassen wollte, kann sich diesen nun unter der Webseite Linux.fm anhören, die mit dem Slogal "Linux Radio : broadcasting the Linux kernel, one source file at a time!" für sich wirbt.
• Eugene Teo hat Git-Trees von Linux 2.6.32, 2.6.36 und dem Hauptentwicklungszweig online gestellt, in denen er die Entwicklungsstände mit Tags kennzeichnet, bei denen die mit CVE-Kennzeichnung versehene Sicherheitslücken behoben wurden. In dem Git-Trees kann man nach CVE-Bezeichnungen suchen und sehnen, wann eine Korrektur integriert wurde.
• Die Firma Knowledge Quest Infotech gewähnt interessierten Testern nach einer Registrierung Zugriff auf eine Beta-Version eines Kernels-Moduls, mit dem sich ZFS-Datenträger unter Linux einbinden lassen. Das Modul ist derzeit nur für x86-64-Varianten der Distributionen Fedora 12, Red Hat Enterprise Linux 6 und Ubuntu 10.04 erhältlich; in einer Tabelle informiert das Unternehmen, welche Features die Beta bereits unterstützt und an welchen noch gearbeitet wird.
• Mike Galbraith hat Patches für Linux 2.6.36.1 und 2.6.37-rc4 online gestellt, mit denen man die Autogruppierung von Prozessen ausprobieren kann, die die Reaktionsgeschwindigkeit von Linux-Systemen in bestimmten Konstellationen erheblich verbessert.

X-Server und Co.

• AMD-Entwickler Alex Deucher hat vergangenen Woche Patches vorgestellt, die den Radeon-DRM-Code des Kernels um Unterstützung für die Grafikeinheit der auch als Bobcat oder Ontario bekannten Fusion-Prozessoren erweitern, die das Unternehmen Anfang nächsten Jahres einführen will. Die Patches zum Ansprechen dieser von AMD Accelerated Processing Unit (APU) genannten CPU-GPU-Kombinationen flossen wenig später in linux-next ein und sollten somit Bestandteil der vermutlich im März oder April erscheinenden Linux-Version 2.6.38 werden.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl). (thl)