Seite 4: Umstrukturierung im Quellcode, Verbesserungen an der Infrastruktur

Inhaltsverzeichnis

Massiv umstrukturiert

Mit 2.6.24 legten die Linux-Entwickler den bisher in separaten Verzeichnissen verwalteten Quellcode für die beiden x86-Architekturen im Verzeichnis arch/x86/ zusammen (siehe etwa diesen Commit). Bisher hatten die beiden Architekturen jeweils eigene Verzeichnisse, obwohl nicht unerhebliche Teile der Codebasis der unter den Kürzeln x86, x86-32, i386, ix86 oder IA32 bekannten 32-Bit-x86-Architektur und der als x86-64, x86_64, x64, AMD64T, EM64T oder IA32e geläufigen 64-Bit-Befehlssatzerweiterung ähnlich oder identisch sind. Das führte in der Vergangenheit gelegentlich dazu, dass eine Korrektur etwa nur in den x86-32-Code unter arch/i386/ Einzug hielt, aber für arch/x86_64/ vergessen wurde – oder umgekehrt.

Bei beiden Architekturen identische Dateien legten die für die Vereinigung zur Hilfe genommenen und eigens programmierten Skripte einfach zusammen; nur für x86-32-Systeme interessanter Code wurde in Dateien mit _32-Anhängsel verschoben, während die Dateinamen mit 64-Bit-spezifischen Code ein _64 enthalten. Durch Include- und Makefile-Tricks soll so etwa für alte x86-32-Systeme benötigter Code nicht in x86-64-Kerneln compiliert werden. In den kommenden Wochen und Monaten wollen die Entwickler dann die Feinarbeit erledigen und die _32- und _64-Dateien weiter aufräumen und, wo es sinnvoll ist, zusammenlegen.

Durch diese massive Umstrukturieren erhoffen sich die Entwickler einfacher wartbaren Quellcode und so langfristig einen zuverlässigeren Kernel mit weniger Fehlern. Durch die Zusammenlegung verringert sich bei der Entwicklung neuer Techniken für x86-Systeme auch der Portierungsaufwand erheblich. Für den Anwender ergeben sich, von diesen indirekten Vorteilen abgesehen, keine nennenswerten Auswirkungen; wer Kernel selbst kompiliert, muss jedoch die Konfiguration anpassen und dort jetzt auswählen, ob er einen 32- oder 64-Bit-Kernel wünscht. Auch Skripte, die etwa den kompilierten Kernel unter arch/{i386,x86_64}/boot/bzImage erwarten, wollen auf die neuen Gegebenheiten abgestimmt werden.

Der Plan zur Vereinigung wurde im vergangenen Juli das erste Mal diskutiert – zahlreiche Entwickler waren von der Idee von Anfang an sehr angetan. Einzelne Hacker sprachen sich aber auch dagegen aus – darunter auch Andi Kleen, der bisherige Verwalter für den Code der x86-32- und x86-64-Architekturen. Torvalds und andere führende Entwickler setzten die Zusammenlegung allerdings durch – in Folge dessen trat der Verwalter für die x86-Architekturen zurück. Diese Aufgabe teilen sich in Zukunft Thomas Gleixner, Ingo Molnar und H. Peter Anvin.

Infrastruktur

Während die Zusammenlegung der x86-32- und x86-64-Verzeichnisse nur wenige Bug-Reports während der 2.6.24-Entwicklung nach sich zog, hatten die Kernel-Hacker bei einer Umstrukturierung des Treiber-APIs für DMA-I/O-Operationen ein weniger glückliches Händchen: Auf einigen Architekturen und mit verschiedenen Treibern zeigte sich Fehlverhalten. Das korrigierten die Entwickler zwar zügig, doch auch einige der unabhängig vom Kernel gepflegten Treiber dürften Anpassungen benötigen – mit deren Umsetzung starten die Treiberbetreuer meist erst, nachdem die Kernel-Entwickler eine neue Linux-Versionen offiziell freigeben.

Nach langer Entwicklungszeit wurden in 2.6.24 nun endlich eine Reihe als "Anti-fragmentation" bezeichnete Patches aufgenommen, die die Fragmentierung im Arbeitsspeicher eindämmen sollen – nach einigen Tagen intensiver Benutzung hatten Kernel bislang kaum mehr größere zusammenhängende Speicherbereiche zur Verfügung.

Entfernt wurde die Möglichkeit, LSMs (Linux Security Modules) zu entladen; mit dem selben Patch wurde auch das externe API für auf LSM aufsetzenden Code entfernt. Die beiden Änderungen sind nicht unumstritten und haben eine lange Diskussion nach sich gezogen.

Beim Aufwachen aus dem Ruhezustand (Suspend-to-Disk/Hibernate) kann auf x86-64-Systemen nun ein beliebiger Kernel das vorher erzeugte Speicherabbild wieder in den Speicher laden und ausführen.

Ein Update für das Ext4-Dateisystem korrigiert einige Fehler und bringt zwei neue Features: Das erstellen und Prüfen von Dateisystemen sollen "Uninitialized Block Groups" beschleunigen, während "Flexible Block Groups" die Verarbeitung von großen Dateien auf Dateisystemen mit kleinen Blockgrößen auf Trapp bringt. Ext4 behält derweil weiter seinen experimentellen Status.

Neben all diesen Änderungen gibt es zahlreiche weitere mit je nach Einsatzgebiet mehr oder weniger Bedeutung für den Linux-Einsatz, die am Ende des Artikels mit einer Kurzbeschreibung auflistet werden.