Home	Artikel > März > Zacks Kernel-News Zack Brown

DevFS lebt weiter

Eine unerwartete Wendung hat das DevFS-Projekt genommen, als sich Ian Kent dazu bereit erklärte, Maintainer zu werden. Der originale DevFS-Code stammt von Richard Gooch und hat eine etwas betrübliche Geschichte. Jahrelang wurde DevFS als externes Patch weiterentwickelt, aber Linus akzeptierte ihn in abgewandelter Form schließlich doch für Kernel 2.4. Einige Entwickler befürchteten jedoch, das Patch könne ein paar schwere Geburtsfehler aufweisen, die sich niemals überwinden ließen, beispielsweise bestimmte Race Conditions. Der einzige Ausweg sei, es komplett durch etwas anderes zu ersetzen. In letzter Zeit war Greg KHs »udev« der am heißesten gehandelte Ersatzkandidat. Aber »udev« hat noch nicht die nötige Reife erreicht, um DevFS komplett ersetzen zu können. Auch andere gut gemeinte ähnliche Produkte tauchten in der Zwischenzeit auf und verschwanden wieder, ohne in einen Zustand zu gelangen, der den Einbau in die offiziellen Kernelsourcen erlaubt hätte. Mit Richard Goochs plötzlichem Verschwinden aus dem Kernel-Entwicklungsprozess schien es, als ob sich auch DevFS schließlich hier einreihen würde. Doch nun sieht es so aus, als ob einige Entwickler, unter anderen Ian, sich doch noch für das Projekt stark machen. Andrew Morton hat sich schon bereit erklärt, DevFS-Patches für Kernel 2.6 anzunehmen - und sei es nur, um die Zeit zu überbrücken, die »udev« noch bis zur Einsatzreife braucht. Andererseits sieht er gute Gründe, DevFS darüber hinaus beizubehalten, sogar im 2.8er Kernel. Offensichtlich hat sich also die Lebensdauer von DevFS noch einmal verlängert.

Hotplug-RAM

Ein Patch von Yasunori Goto erlaubt es, RAM-Chips im laufenden Betrieb auszutauschen, es ist aber ein Mehrprozessorsystem erforderlich. Derzeit ist das Patch nur auf Intels 32-Bit-Architektur mit Kernel 2.6 lauffähig, eine 64-Bit-Portierung ist geplant. Das Patch geht auf die Arbeiten von Toshihiro Iwamoto zurück, der schon im Herbst letzten Jahres den Kernel um die Möglichkeit erweitert hatte, Speicher im laufenden Betrieb zu entfernen.

Cryptoloop möglicherweise vor Ablösung

»dm-crypt« von Christoph Saout ist ein neuer Mechanismus zum Verschlüsseln von Dateisystemen, er arbeitet als Target für Device Mapper. Laut Clemens Fruhwirt, dem Maintainer von Cryptoloop, ist »dm-crypt« seinem eigenen Projekt "weit überlegen". Clemens empfahl nach der Analyse von »dm-crypt«, Cryptoloop im Kernel 2.6 als veraltetes Feature weiterhin zu führen, bis »dm-crypt« voll funktionsfähig ist. Danach könnte die Zeit dafür gekommen sein, Cryptoloop komplett zu entfernen und das Loopback-Device nur noch für Dateien zu verwenden. Andrew Morton steht dieser Idee sehr aufgeschlossen gegenüber und glaubt, dass diese Zeit irgendwann im Verlauf der Entwicklung zu 2.8 kommen wird. Cryptoloop selbst ist noch eine ziemlich neue Entwicklung und zudem der erste Versuch transparente Datenverschlüsselung auf einem unverschlüsselten Dateisystem zu betreiben. Sicherheitsbewusste Anwender hatten diese Möglichkeit seit Jahren gewünscht. Anfangs wurde Cryptoloop als eine wunderbare Lösung des Problems begrüßt, inzwischen scheint es so, als wäre es wie sein wahrscheinlicher Nachfolger »dm-crypt« nur ein Schritt auf dem Weg. Sicherlich wird es bei jeder Lösung zum Speichern verschlüsselter Daten viele Anfragen zum Einbau künftiger Erweiterungen geben.

Neues Echtzeit-Patch

Bernhard Kuhn, Entwickler bei Metrowerks/Motorola, hat eine neue Möglichkeit vorgeschlagen, den Linux-Kernel hart echtzeitfähig zu machen, indem Spinlocks und Interrupts priorisiert werden. Im Gegensatz zu RTAI oder RT-Linux benötigt diese Methode also keinen zusätzlichen Echtzeit-Kernel. Die erste Version des Patches funktioniert nur auf Systemen mit Intel-Architektur, einem Prozessor und Kernel 2.4. Sie soll lediglich die Funktionsfähigkeit des Prinzips zeigen. Die Resonanz auf der Kernel-Mailingliste ist vorerst jedoch gering.

Maintainers-File und Entwickler-Eitelkeiten

Die Zukunft der »MAINTAINERS«-Datei wurde unlängst zum Anlass einer kontroversen Diskussion. Ursprünglich war »MAINTAINERS« dazu gedacht, Entwicklern die richtigen Ansprechpartner für ihre Patches mitzuteilen. Die Lage änderte sich jedoch, als das so genannte Leutnant-System entstand, also eine weitere Hierarchie-Ebene von besonderen Entwicklern zwischen die Maintainer der Sub-Projekte und Linus Torvalds geriet. Selbst wenn ein Entwickler jetzt ein Patch an den richtigen offiziellen Maintainer schickt und dieser den Vorschlag befürwortet, ist dessen Schicksal trotzdem ungewiss. Die Maintainers-Liste hat also etwas von ihrer einstigen Bedeutung eingebüßt. Gleichwohl wird sie penibel gepflegt und in regelmäßigen Abständen aktualisiert. Im Statusdenken einiger Entwickler spielt sie dafür zunehmend eine Rolle. Das wurde jüngst deutlich, als der Echtzeit-Linux-Spezialist Karim Yaghmour versucht hat, Philippe Gerum als Maintainer des Adeos-Projekts und Paolo Mantegazza als Maintainer der Echtzeit-Erweiterung RTAI hinzuzufügen und gleichzeitig Victor Yodaiken als RT-Linux-Maintainer zu entfernen. Weder RTAI noch RT-Linux sind Bestandteile des offiziellen Kernels. Es läuft also letztlich auf die Frage hinaus, ob jemand Maintainer eines Kernel-Features sein kann, wenn das betreffende Feature gar nicht im offiziellen Kernel ist. Außerdem stellt sich die Frage, ob die Maintainers-Datei nicht langsam zu einem Instrument der Eitelkeit verkommt. Die Entwicklergemeinde ist gespalten. Einige stehen auf dem Standpunkt: Wenn es den entsprechenden Code im Kernel nicht gibt, dann kann es auch keinen Maintainer dafür geben. Die Gegenseite ist der Auffassung, dass jedes Feature, das aktiv weiterentwickelt wird, mit dessen Maintainer in die Liste gehört, denn schließlich gelangt es bei entsprechender Reife möglicherweise in den Kernel und dann wird ein Ansprechpartner benötigt. Das File »MAINTAINERS« hilft beim Finden der richtigen Ansprechpartner, dient jedoch immer auch der Selbstdarstellung der Entwickler.

XFS im Kernel 2.4

XFS hat es endlich auch offiziell in den Kernel 2.4 geschafft. Fast wäre das Journaling Filesystem von SGI noch gescheitert. Denn als klar wurde, dass die Veröffentlichung von 2.6 bevorstand, trat Marcelo Tosatti bei 2.4 kräftig auf die Bremse und weigerte sich neue Features aufzunehmen. Dieser plötzliche Schnitt hat viele Entwickler stark verärgert und jene aus dem XFS-Lager machten sich am deutlichsten bemerkbar. Offensichtlich hatten sie zuvor besonders intensiv an XFS gearbeitet, um es in den Kernel zu bekommen, und waren von Marcelo darin noch bestärkt worden. An seiner Entscheidung, den künftigen Erweiterungen von 2.4 einen Riegel vorzuschieben, haben die Vorfälle um XFS jedoch nichts geändert. Im Gegenteil, er scheint sogar darin noch bestärkt worden zu sein. (uwo)