News aus der Kernel-Welt.

Die Xen-Entwickler haben mit Transcendent Memory, kurz Tmem, eine ungewöhnliche Art Arbeitsspeicher implementiert. Im Unterschied zum herkömmlichen Speicher ist Tmem von unbekannter, dynamisch veränderbarer Größe und lässt sich vom Kernel nur indirekt adressieren.

Ist dieser Speicher zudem als »ephemeral« konfiguriert, kann er ohne Vorwarnung einfach verschwinden. Sinn der Sache ist, Userspace-Programmen größere Mengen verfügbaren Speichers vorzuspiegeln. Derzeit ist Tmem nur in Xen implementiert, das Verfahren ließe sich aber auch anderswo umsetzen. Der Oracle-Entwickler Dan Magenheimer hat mit einigen Kollegen Patches eingereicht, die ein API für Tmem implementieren und die dafür nötige Infrastruktur schaffen.

Einige Mainline-Kernelentwickler haben bereits Interesse gezeigt. In der Diskussion auf der Mailingliste standen zwar Sicherheitsbedenken in Sachen Denial of Service im Vordergrund, es gab jedoch keine grundsätzlich ablehnenden Stimmen.

Der italienische Entwickler Marco Stornelli hat das Dateisystem Pram-FS [http://pramfs.sourceforge.net] zur Aufnahme in den Kernel vorgeschlagen. Pram-FS arbeitet mit nichtflüchtigem Arbeitsspeicher zusammen, der den Speicherinhalt über einen Reboot samt Aus- und Einschalten hinweg bewahren kann. Damit eignet es sich für Geräte wie Handhelds oder Mobiltelefone.

Schon 2004 hatte die Embedded-Firma Montavista versucht, das Dateisystem in den offiziellen Linux-Kernel zu bringen. Das scheiterte damals an Patentansprüchen, die es im Zusammenhang mit dem Code gab. Seither seien die Algorithmen laut Marco komplett umgeschrieben und Montavista habe die Patentansprüche fallen lassen.

Damit rückten technische Argumente in den Vordergrund: Ist Pram-FS stabil genug? Bietet es Dateisystem-Features wie etwa Hardlinks? Mitten in der Diskussion wurde klar, dass Pavel Machek Pram-FS strikt ablehnt: Für ihn gibt es keinen Grund, ein neues Dateisystem einzuführen, wenn man stattdessen Ext 2, Ext 3 oder eine Abwandlung des Ramdisk-Code für persistenten Speicher einsetzen könne.

Pavel ließ sich nicht umstimmen, obwohl einer von Marcos Tests zeigte, dass Pram-FS wesentlich schneller arbeitet als Ext 2. Offenbar muss Pram-FS erst Hardlinks, Journaling und andere Features ausgewachsener Dateisysteme implementieren, ehe die Aufnahme in den Kernel wieder zur Debatte steht.

Das Dateisystem Pram-FS ist anschaulich dokumentiert, lässt aber noch einige Features wie beispielsweise Hardlinks vermissen.

Pierre Ossman ist als Maintainer des Subsystems für Multimediakarten (MMC) zurückgetreten. Er berichtete, schon seit über einem Jahr habe er nicht mehr richtig Zeit für den Code gehabt.

Einen geeigneten Nachfolger hat Pierre nicht im Sinn, also dachten einige zunächst an Ian Molton. Der hatte zwar schon ernsthafte MMC-Arbeit geleistet, will aber die Betreuung nicht schultern, da er nicht besonders tief in den Code vorgedrungen sei. Doch erklärte Ian sich bereit, eingehende Patches als CC-Adressat zu begutachten. Auch Matt Fleming und Roberto A. Foglietta sowie Philip Langdale meldeten sich als Helfer. Übergangsweise möchte Andrew Morton als Maintainer einspringen, wie er es "für ungefähr 1000 andere Subsysteme" auch tue.

Plötzlich erschienen reihenweise Patches auf der Mailingliste: Paul Mundt und Ohad Ben-Cohen sandten Code ein und Adrian Hunter wies auf 32 Patches hin, die bisher unbeachtet geblieben waren. Nun suchen die Entwickler nach einem geeigneten Verfahren, um die eingehenden Patches zu abzuarbeiten.

Der österreichische Linux-Benutzer Clemens Eisserer hat sich an die Mailingliste gewandt und nach der Online-Defragmentierung im Dateisystem Ext 4 gefragt. Diego Calleja antwortete, das Feature sei in die Kernel-Release 2.6.31 eingeflossen.

Das las Clemens gerne, denn Ext 4 vermeide Fragmentierung zwar recht erfolgreich, in manchen Fällen wäre aber Defragmentierung nützlich, etwa bei der SQLite-Datenbank des Firefox-Browsers.

Der Ext-4-Maintainer Theodore T\'so schaltete sich ein und berichtete nüchtern den derzeitigen Entwicklungsstand: Die Online-Defragmentierung sei noch nicht ganz fertig. Das passende Userspace-Programm beispielsweise benötige noch viel Arbeit, zudem sei es von einigen I/O-Controls abhängig, die noch gar nicht im Kernel vorhanden seinen. Außerdem könne die Defragmentierung derzeit nicht gut mit freiem Plattenplatz umgehen. Theodore hofft, dass es bald Fortschritte in diesen Punkten gibt, leider seien aber zu wenige Entwickler am Werk.

Der Embedded-Spezialist Albin Tonnerre hat Patches eingeschickt, die den Komprimierungsalgorithmus LZO für das Kernelimage verwenden. Das Verfahren erreicht zwar eine geringere Kompressionsrate als die gängige Gzip-Methode, ist aber beim Entpacken schneller, was auf Embedded-Systemen von Vorteil ist. Wenn der Unterschied bei den Archivgrößen nicht zu groß ist, der Geschwindigkeitsgewinn beim Entpacken aber deutlich ausfällt, könnte LZO in den Kernel einziehen. Allerdings muss Albin bis dahin noch einige weitere technische Details klären.

Der Kernel.org-Postmaster Matti Aarnio arbeitet an seiner eigenen Mailinglisten-Software, die eines Tages die Stelle des derzeit eingesetzten Majordomo einnehmen soll. Das Programm verwendet MySQL, um Daten wie die Abonnentenliste zu speichern. Die Mails selbst dagegen landen nicht in der Datenbank. Matti möchte mit seinem Tool außerdem die Sicherheit verbessern: Ein Benutzer sollte das Abonnement eines anderen nicht beenden können. Warum es unbedingt ein komplett neu geschriebener Listenmanager sein muss, begründet der Postmaster aber nicht. Unter [listmanager@vger.kernel.org] läuft die Software in experimentellem Betrieb. (Zack Brown/mhu)