Kernel-Log: Llano-Unterstützung, Union-Dateisysteme

Treibercode für den Grafikchip der Llano-APUs von AMD hat es noch in Linux 3.0 geschafft – dessen Versionsnummer vielleicht doch 3.0.0 lauten muss. Derweil wird mal wieder über den besten Ansatz für Overlay- oder Union-Dateisysteme diskutiert.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Lesezeit: 11 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In der Nacht von Montag auf Dienstag hat Linus Torvalds die dritte Vorabversion von Linux 3.0 freigegeben. Mit ihr stieß Unterstützung für den Grafikkern von AMDs am Dienstag vorgestellten Llano-Prozessoren zum Kernel – die Änderungen schienen Torvalds wohl klein und ungefährlich genug, um sie auch mehr als eine Woche nach Ende des Merge Window noch in den Hauptentwicklungszweig aufzunehmen.

Nach dem Versionssprung auf 3.0 flossen zudem einige Änderungen ein, die Probleme mit zweistelligen Versionsnummern beseitigen. In einer daraufhin entstandenen Diskussion deutet Torvalds an, den nächsten Kernel vielleicht doch "3.0.0" zu nennen, wenn keine Tricks gefunden werden, damit ältere Programme mit einem "3.0" klarkommen. Schwierigkeiten mit einer zweistelligen Versionsnummer zeigen unter anderem ältere Versionen der Module-Init-Tools (Depmod und Co.), Mdadm sowie die LVM2- und Device-Mapper-Werkzeuge. Torvalds scheint aber langfristig auf Versionsnummern mit zwei Stellen wechseln zu wollen. In einer anderen Diskussion hat Torvalds erklärt, Programme sollen möglichst keine Annahmen über den Aufbau der Versionsnummer enthalten.

Rafael J. Wysocki hat kurz vor der Freigabe des RC3 neue Regression Reports veröffentlicht. Demnach zeigte der Hauptentwicklungszweig am Wochenende 7 Fehler, die Linux 2.6.39 nicht aufwies; zudem sind 18 Fehler bekannt, die mit 2.6.38 nicht auftraten.

Viele Linux-Distributionen nutzen für ihre Live-Medien Overlay- oder Union-Dateisysteme, um ein beschreibbares Dateisystem über ein schreibgeschütztes zu legen, damit man beispielsweise nach dem Booten von einem nicht beschreibbaren Dateisystem einer CD oder DVD Software nachinstallieren kann. Fedora verwendet dazu den Device Mapper; bei anderen Distributionen wie Ubuntu kommt das Overlay-Dateisystem aufs zum Einsatz, das allerdings außerhalb der Kernelquellen gepflegt wird. Verschiedene Entwickler arbeiten daher seit Jahren an Overlay- oder Union-Funktion auf Dateisystemebene, die den Qualitätsansprüchen der Kernel-Hacker genügt, damit sie in den Hauptentwicklungszweig einziehen kann.

Der durch Fuse bekannte Entwickler Miklos Szeredi hat seine Overlay-Lösung jetzt zur Aufnahme bei Linux 3.1 vorgeschlagen. Die daraufhin entstandene Diskussion erweckt ein wenig den Eindruck, dass auch einige der Kernel-Hacker endlich eine Lösung im offiziellen Kernel sehen wollen. Die Dateisystemspezialistin Valerie Aurora merkt allerdings an, die Lösung von Szeredi habe möglicherweise einige Probleme. Aurora hat zusammen mit anderen Entwicklern ein alternatives Union-Framework vorangetrieben, sich aus der Kernel-Entwicklung aber vor einigen Monaten weitgehend zurückgezogen.

Die jetzige Diskussionen scheint im Sande zu verlaufen – das Thema dürfte aber vermutlich in nächster Zeit wieder aufkommen. Einige Hintergründe zum Ansatz von Szeredi liefert ein LWN.net-Artikel aus dem September 2010. Er verweist auf viele ältere LWN.net-Artikel, die einige Probleme beim Überlagern von Dateisystemen erläutern, die manche außerhalb des Kernels gepflegte Lösungen ignorieren.

  • Die durch den USB-3.0-Code bekannte Sarah Sharp hat einen "USB mini-summit" angekündigt, der im Rahmen der LinuxCon Vancouver stattfinden soll. Daraus entstand eine Diskussion, die sich unter anderem mit Techniken zum Weiterreichen von USB-Geräten an virtuelle Maschinen beschäftigt. An der hat sich auch Hans de Goede beteiligt, der kürzlich einem Blog-Eintrag zu einer von ihm vorangetriebenen Lösung verfasst hat.
  • Die bereits erwähnte Diskussion zum Union- und Overlay-Dateisystemen enthielt auch einige Beiträge zu Userspace-Dateisystemen. Torvalds erwähnt dort, dass Fuse zwar für gewisse Dinge gut sei, für das Root-Dateisystem aber ungeeignet sei. Ein Tuxera-Entwickler der NTFS-Treiber für den Linux-Kernel und Fuse erklärte, der Kernel-Treiber sei viel schneller, als ein Userspace-Treiber je werden könne.
  • Amir Goldstein hat Patches veröffentlicht, die Ext4 um eine Snapshot-Funktion erweitern. In der daraus entstandenen Diskussion merken einige Entwickler an, dass der Device Mapper durch das noch in Entwicklung befindliche "Multisnap" ähnliche Funktionen ermögliche, ohne dass tief greifende Änderungen an Ext4-Code nötig seien (u.a. 1, 2).
  • Die im letzten regulären Kernel-Log erwähnten Probleme rund um die Linux-Unterstützung von (U)EFI haben weitere Diskussionen nach sich gezogen. In einem Beitrag spricht Torvalds alles andere als positiv über (U)EFI und verwendet dabei deutliche Worte; er bezeichnet aber auch die Unterstützung von (U)EFI in Linux als kaputt. Matthew Garrett berichtet in seinem Blog derweil über einen praktischen Nutzen, den EFI bringt: Ein Ort zum Speichern von Daten, die helfen können, die Ursache von Systemabstürzen zu finden.
  • Keith Packard übernimmt die Pflege des DRM/KMS-Treiber für Notebook- und Desktop-Grafikchips von Intel; er liefert und erhielt in dem Rahmen einige Tipps zum Einsatz von Git zur Kernel-Entwicklung.
  • In einer Diskussion um ein im Longterm-Kernel 2.6.32 bislang nicht korrigiertes XFS-Problem stellte Kernel-Urgestein Theodore Tso klar, dass Korrekturen nicht magisch in die Stable- oder Longterm-Kernel eingehen, sondern es eines Entwicklers bedarf, der sich um solche Dinge kümmere; später führte er noch aus, dass dies nicht der Job der Stable- und Longterm-Betreuer sei.