Seite 2: Treffen der Kernel-Entwickler

Inhaltsverzeichnis

Kernel Summit

Unter den Konferenzen, die parallel oder im Anschluss der diesjährigen LinuxCon Europe stattfanden, war auch der Kernel Summit. Eine weitgehend geschlossene Veranstaltung, zu der jährlich einige der wichtigsten Kernel-Entwickler eingeladen werden, um von Angesicht zu Angesicht über die weitere Entwicklung von Linux zu diskutieren. Alte LWN.net-Berichte zeigen, dass es dort immer mal wieder heftige Debatten gab – etwa über das Vorgehen bei der Entwicklung allgemein oder die Aufnahme bestimmter Features. Seit einigen Jahren geht es aber offenbar gelassener zu; diesen Eindruck hatten wir auch in diesem Jahr.

Zu den diskutierten Aspekten zählte unter anderem die Platzierung von Tracepoints und deren Bedeutung für die Schnittstellen zwischen Kernel und Userspace. Die Betreuer einiger Subsysteme des Kernels lehnen den Einbau von Tracepoints aus Angst ab, die Punkte zur Ablaufverfolgung der Kernel-eigenen C-Funktionen würden fortan zum als stabil erachteten Interface des Kernels zählen; daher könnten Tracepoints dann nicht entfernt werden, wenn der Code erheblich umgebaut würde und letztlich so anders arbeite, dass ein existierende Tracepoint keinen Sinn mehr ergebe. Diese Diskussion läuft schon seit Jahren (u. a. 1, 2). Torvalds forderte die Kernel-Entwickler auf, mutiger zu sein; man habe schon mehr Zeit mit der Diskussion über möglicher Probleme verschwendet, als mit der Lösung tatsächlich aufgetretener Probleme. Wenn tatsächlich Probleme auftauchen, werden sich schon technische Lösungen finden.

Im Rahmen der Diskussion betonte Torvalds zudem, was er auch regelmäßig auf der Kernel-Mailingliste anführt: Änderungen am Kernel dürfen normale Anwendungen nicht kaputt machen ("You can never ever break userspace"). Wenn ein normaler Anwender ein Problem melde, an dem eine Änderung am Kernel schuld sei, gebe es dafür keinerlei Entschuldigung; die Ursache muss im Kernel behoben werden.

Tempo der Stable- und Longterm-Kernel

Greg Kroah-Hartman kündigte an, den Patch-Fluss bei den Stable- oder Longterm-Kerneln etwas zu verlangsamen: Änderungen würden erst in die Warteschlange für neue Kernel dieser Serien eingereiht, wenn der Patch in einen RC des Hauptentwicklungszweigs eingeflossen sei. Dadurch sollen die Änderungen besser gestestet werden, bevor sie in Stable- oder Longterm-Kernel auftauchen. Bislang reichte es, dass Patches in den Hauptentwicklungszweig eingeflossen waren. Beim Beheben kritischer Fehler sollen unnötige Verzögerungen aber vermieden werden.

Diskussionen zum Umgangston zwischen den Kernel-Entwicklern, der im Sommer für Debatten sorgte, standen nicht auf der Agenda; das Thema wurde auf den Fluren aber hier und da angesprochen. Sarah Sharp, die die Debatten ausgelöst hatte, berichtete indes über das FOSS Outreach Program for Women (OPW). In dessen Rahmen haben Sharp und einige andere Entwickler versucht, Frauen an die Kernel-Entwicklung heranzuführen. Sie zeigte sich zufrieden mit dem Verlauf der kürzlich abgeschlossenen Runde: Die sieben Teilnehmerinnen steuerten so viele Änderungen bei, dass sie nur knapp die Top 10 in der LWN.net-Auswertung zu den in Linux 3.11 eingeflossenen Änderungen verfehlten. Einige weitere Hintergründe zum Ansatz und Erfolg des Programms liefern die Folien eines Vortrags, in dem Sharp das OPW auf der LinuxCon Europe vorgestellt hat; weitere Informationen finden sich in einer Mail von Sharp.

In Verlauf dieser Diskussion wies ein Kernel-Entwickler darauf hin, die Zahl der in den Kernel eingebrachten Änderungen sei nur eingeschränkt sinnvoll, um Beiträge zum Kernel zu bewerten. Auch Torvalds ging darauf ein: Die Subsystem-Maintainer sollten darauf achten, dass Änderungen nicht in zu kleinen Patches eingereicht würden, nur um die Zahl der Commits hochzutreiben.

Eine längere Diskussion gab es um die bereits vorangetriebenen Umbauten am Code für die Control Groups (Cgroups) und deren Auswirkungen auf ABI (Application Binary Interface) und API (Application Programming Interface) von Linux. Im Zuge dessen soll es nämlich ein neues API geben, das parallel zum bisherigen nutzbar sein soll; die Kernel-Entwickler machen sich unter anderem Sorgen, dass Userspace-Anwendungen nicht auf das neue API umsteigen. Diese und viele andere Punkte, die auf dem Kernel Summit angesprochen wurden, sind für einfache Linux-Anwender oft nicht sonderlich von Belang und vornehmlich für Kernel-Entwickler relevant. Diese dürften in den kommenden Wochen Details in Artikeln bei LWN.net finden, das traditionell vom Kernel Summit berichtet.

Auf der Mailingliste des Kernel Summits finden sich einige Dokumente, die Hintergründe zu den besprochenen Themen erläutern. Darunter etwa Präsentationsfolien von Grant Likely, die einige Probleme von Devices Trees (DT) erläutern; über solche erhalten Linux-Kernel auf modernen ARM-Plattformen oft Informationen, die zur Hardware-Ansteuerung essenziell sind. Probleme rund um Device Trees auszuräumen war eines der meistdiskutierten Themen des Kernel Summits. Dabei kam auch zur Sprache, doch ACPI statt Device Trees einzusetzen – dieser Gedanke behagt einigen Entwicklern allerdings gar nicht. Es wirkte indes wie eine ausgemachte Sache, dass die Entwickler in Zukunft verstärkt UEFI statt des bislang oft verwendeten Uboot nutzen wollen, um Linux auf ARM-Plattformen zu booten.