Beim Kernelrückblick gibt es ab sofort etwas neues, abseits der Entwicklung des Kernels selbst: Unter „Kurz erläutert“ werden künftig Begriffe, Funktionen oder Konzepte aus dem Kernel-Umfeld etwas ausführlicher als in einem Nebensatz erklärt. Da ich das ja nicht zum Selbstzweck mache, bin ich für Anfragen, was euch interessiert, dankbar.
Der Kernelrückblick ist, neben vielen anderen interessanten Themen, in der aktuellen Ausgabe von freiesMagazin enthalten.
Kaum wurde Kernel 2.6.33 veröffentlicht, begann der Entwicklungszyklus mit dem „Merge Window“ von neuem. Anfang März veröffentlichte Torvalds dann 2.6.34-rc1 [1]. Er gab aber bekannt, dass er noch nicht berücksichtigte Anfragen zur Aufnahme noch nachträglich einpflegen würde und verlängerte damit gewissermaßen das Merge Window. Dennoch machte er darauf aufmerksam, dass bis zum letzten Moment hinausgeschobene Pull Requests auf die Aufnahme frühestens in 2.6.35 hoffen können. Unter den Änderungen, die es geschafft haben, sind zum Beispiel die Dateisysteme LogFS [2] und Ceph [3].
Ceph stellt ein verteiltes Dateisystem dar, das die Daten über mehrere Rechner so verteilt, dass kein Fehlerpunkt entsteht, der das ganze System kompromittieren kann. Konkret wurde die Client-Komponente für den Zugriff auf das Dateisystem in den Kernel aufgenommen, der Serverteil ist als Daemon implementiert.
LogFS dagegen ist ein für Flash-Speicher angepasstes Dateisystem, das logstrukturiert speichert. Es fügt neue oder geänderte Daten an bereits beschriebene Speicherbereiche an und überschreibt bereits belegte Bereiche erst, wenn keine freien mehr zur Verfügung stehen. Dadurch ist die Wiederherstellung von Daten sehr einfach, aber auch beim Einsatz in Verbindung mit Flash-Speichern ist dieses Vorgehen sehr praktisch, da der Speicher sehr gleichmäßig genutzt wird.
Bislang musste das in 2.6.30 aufgenommene FS-Cache, das Zugriffe auf bestehende Netzwerkdateisysteme wie NFS durch Zwischenspeicherung der Daten beschleunigt, mit dem Stigma der „experimental“-Markierung leben. Diese wurde nun entfernt, sodass die Funktion nun von den Distributoren genutzt werden kann.
Auch Devtempfs wurde davon befreit, hauptsächlich weil es von den meisten größeren Distributionen laut Kay Sievers sowieso schon verwendet wird. Devtmpfs wurde erst vor kurzem in 2.6.32 aufgenommen. Es stellt eine Ergänzung zu Udev [4] dar und wird vom Kernel genutzt, um das Pseudo-Dateisystem unter /dev zu verwalten, in dem die an das System angebundenen Geräte eingehängt werden.
An der Grafikfront erhält der Radeon-Treiber nun KMS-Unterstützung für Evergreen-Chipsätze (Radeon HD 5xxx). Die Arbeiten an Nouveau, dem freien Treiber für NVIDIA-Chipsätze, schreiten voran. So kann nun auf die proprietäre Firmware für Karten der NV50-Generation verzichtet werden, die zuweilen Grund für kontroverse Diskussion war. Nouveau erzeugt die Firmware nun einfach selbst.
Auch an der Beseitigung des Big Kernel Lock (BKL) wird weiter gearbeitet. Diesmal war das USB-Subsystem dran, in dem Oliver Neukum in verschiedenen Komponenten den BKL gegen weniger gierige Sperrmechanismen austauschte.
Das von Torvalds verkürzte Merge Window sorgte auch für Unmut. So entbrannte in der E-Mail-Diskussion um die Übernahme der SCSI-Aktualisierungen [5] eine heftige Debatte um das frühzeitige Einreichen von Merge Requests (Bitten um Aufnahme von Änderungen in den Kernel). Dabei stellte er klar, dass der Zeitraum zur Übernahme von Änderungen nicht zwangsläufig zwei Wochen betrage, sondern künftig nach seinem Gutdünken auch kürzer ausfallen könnte. Damit zielt er insbesondere auf die Entwickler, die kurz vor dem von ihnen vermuteten Ende des Merge Window noch schnell ihre Anfragen einreichen und Torvalds damit die letzten Tage des Merge Window „zur Hölle machen“. Größere Änderungen sollten seiner Ansicht nach zu Beginn des Entwicklungszyklus bereitstehen und dann auch zeitnah zur Aufnahme eingesandt werden.
Den Rausschmiss aus dem staging-Zweig hatten die Android-Entwickler selbst verschuldet (siehe „Der Februar im Kernelrückblick“, freiesMagazin 03/2010 [6]). Zu wenig wurde an dem vorhandenen Code weiterentwickelt, zudem nutzt Android zum Beispiel vom Linux-Kernel abweichende Sperrmechanismen und bringt ein eigenes Sicherheitskonzept mit.
Bereits auf der FOSDEM [7] äußerte Kroah-Hartman gegenüber dem Linux-Magazin, dass die Android-Entwickler bereits ihren Willen signalisiert hätten, Android wieder in den Linux-Kernel zurückzuführen. Chris DiBona, Googles Open-Source-Manager, äußerte jedoch, dass hierfür viele Änderungen notwendig seien und es mehrere Jahre dauern würde, bis die Unterschiede zwischen Linux- und Android-Kernel ausreichend verringert wären, um die Wiedervereinigung zu ermöglichen [8].
Quellen:
[1] http://lkml.org/lkml/2010/3/8/280
[2] http://logfs.org
[3] http://ceph.newdream.net
[4] http://de.wikipedia.org/wiki/Udev
[5] http://lkml.org/lkml/2010/3/10/273
[6] http://www.freiesmagazin.de/freiesMagazin-2010-03
[7] http://fosdem.org/2010/
[8] http://www.pro-linux.de/NB3/news/1/15393/android-code-soll-in-den-linux-kernel-zurueck.html
Kurz erläutert: „Merge Window“
Mit dem „Merge Window“ beginnt der Entwicklungszyklus des Kernels. In diesem Zeitraum werden neue Funktionen, Treiber oder anderweitige größere Neuerungen aus verschiedenen Entwickler-Zweigen in den aktiven Entwicklungszweig des Kernels übernommen. Dieser Zeitraum dauert meist zwei bis drei Wochen und wird mit Veröffentlichung des ersten Release Candidate (-rc1) beendet. Die Begrenzung dieser Zeitspanne soll verhindern, dass zu große Änderungen die weitere Entwicklungsphase beeinträchtigen, sodass nach dem „Merge Window“ überwiegend nur Patches aufgenommen werden, die der Behebung von Fehlern im Kernel dienen.