Login
Newsletter
Werbung

Di, 24. April 2018, 12:06

Software::Kernel

Vetter: Zweierlei Maß beim Review von Kernel-Beiträgen

Grafik-Entwickler Daniel Vetter kritisiert die Kernel-Entwicklungsmethodik und sagt einigen Teilsystemen erhebliche Probleme voraus. Er bemängelt außerdem, dass Code von Subsystem-Betreuern oft ohne Review übernommen wird.

Larry Ewing

Die Entwicklung des Linux-Kernels erfolgt bekanntlich stark verteilt. zu jedem Zeitpunkt existieren unzählige Forks und Zweige des Kernels, von denen viele allerdings dazu dienen, Änderungen in einem Subsystem zu sammeln und dann gebündelt an Linus Torvalds weiterzureichen, dessen Kernel-Repositorium als das offizielle definiert ist. So entsteht eine mehrstufige Hierarchie, innerhalb derer der Code zu Linus Torvalds hochwandert. Zu unterscheiden sind daher zwei Arten von Kernel-Entwicklern. Zum einen gibt es die normalen Beitragenden, die ihre Änderungen als Patch in den Mailinglisten präsentieren, aber keinen Code in den Kernel einchecken können. Dazu benötigen sie die Subsystem-Betreuer (Maintainer), die die zweite Art von Entwicklern sind. Dies gibt den Maintainern einige Macht, und die Entwickler müssen sich mit ihnen arrangieren, was nicht immer leicht ist.

Vetter, selbst im Grafik-Subsystem des Kernels aktiv, wollte nun wissen, wieviele Patches die Maintainer selbst erstellen, und wieviele davon ein Review erfahren in Relation zu den anderen Patches. Mit Hilfe der Git-Historie und einigen Skripten konnte er diese Information extrahieren, wobei er einige Spezialfälle außer Acht ließ, die nach seinen Beobachtungen aber kaum Auswirkungen auf die Ergebnisse haben.

Vetter ermittelte, dass die Zahl der Patches, die von den Maintainern selbst geschrieben wurden, im Lauf der Zeit Kernel-weit abgenommen hat und jetzt kaum noch 15% der gesamten Änderungen ausmacht. Daraus schließt er, dass viele Maintainer kaum noch Zeit für Code-Entwicklung haben und an der Grenze zur Überlastung stehen. Es gibt allerdings starke Unterschiede zwischen den Subsystemen. So gibt es im Grafik-Subsystem eine ausreichende Zahl von Maintainern, auch durch das gezielte Aufbauen von neuen Maintainern, die 30-40% der Änderungen in diesem Subsystem schreiben.

Ähnlich große Schwankungen gibt es bei dem Anteil der Maintainer-Änderungen, die ein Review erhalten. Im Grafik-Subsystem liegt dieser Anteil seit Linux 4.5 um die 80%, während es im Rest des Kernels durchschnittlich 30% sind.

Für Vetter bedeutet das, dass im Kernel insgesamt zu wenig getan wird, um neue Maintainer zu gewinnen. Die Zahl der Maintainer kann daher nicht mit dem Kernel-Wachstum Schritt halten und in einigen Jahren könnte es große Probleme geben, da die Maintainer dann zu 100% mit dem Integrieren und Review von Patches ausgelastet sind. Sie werden dann zum Engpass, der den Fortschritt des Kernels hemmt.

Ein zweiter Kritikpunkt Vetters ist, dass die aktuelle Review-Praxis mit zweierlei Maß misst. Code von normalen Beitragenden kann nie ohne Review in den Kernel gelangen, die Review-Quote ist daher 100%. Bei Code von den Maintainern bestehen die meisten Subsysteme derzeit nicht auf einem Review, dieser Code gelangt zu fast 70% und in einigen Bereichen zu 90% ohne Review in den Kernel. Dass es auch anders geht - und nach Vetters Meinung auch praktiziert werden sollte - zeigen Subsysteme wie XFS mit 100% Review-Rate und verbindlicher Review-Richtlinie, arm64 mit 91% und GPU mit 83%.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung