Kernel-Log: x32-ABI umgeht Nachteile des 64-Bit-Betriebs

Inhaltsverzeichnis

Die Intel-Entwickler H. Peter Anvin und H.J. Lu haben auf der LKML eine Diskussion zu System-Call-Nummern für ein x32-ABI (Application Binary Interface) angestoßen. Ein für dieses ABI kompiliertes Programm läuft im 64-Bit-Modus von x86-64-Prozessoren, nutzt aber nur 32-Bit große Pointer und Datenfelder. Das soll den mit dem 64-Bit-Betrieb einhergehenden Overhead vermeiden, denn viele verbreitete Anwendungen brauchen keine 64-Bit-Pointer und -Datenfelder. Eine x32-ABI-Anwendung kann so zwar nur 4 GByte Speicher nutzen, allerdings den kompletten x86-64-Registersatz sowie Techniken wie das SYSCALL64-Interface ansprechen – die stehen im 32-Bit-Kompatibilitätsmodus nicht zur Verfügung, den x86-64-Distributionen heutzutage zum Ausführen von 32-Bit-Anwendungen nutzen.

Das x32-ABI verspricht so die Vorteile von x86-64-/x64-Prozessoren zu nutzen, umgeht aber einige Nachteile des 64-Bit-Betriebs. Dadurch sollen die Anwendungen flotter arbeiten, wie die Homepage zum x32-ABI verspricht. Es gibt aber nur eine Handvoll Messwerte; zudem nutzt die GCC-Unterstützung für das x32-ABI bisher einige Optimierungsmöglichkeiten nicht, was Vergleiche der Ergebnisse erschwert.

Linus Torvalds war mit einigen Aspekten der kernelseitigen Unterstützung von x32 allerdings unzufrieden; einige Hintergründe dazu erläutert LWN.net in dem Artikel "The x32 system call ABI". Für einige der dort angesprochene Probleme scheinen sich aber Lösungen abzuzeichnen.

Die Homepage von x32-ABI verweist auf einige Pakete, die ein aktuelles Fedora um Unterstützung für das neue ABI erweitern -- aufgrund von Wartungsarbeiten bei Kernel.org sind die aber derzeit nicht erreichbar. Inwieweit gängige Linux-Distributionen für x86-64/x64-Systeme das x32-ABI von Haus aus unterstützen, muss die Zeit zeigen. Das größte Interesse an diesem Modus dürften x86-Embedded-Entwickler haben, denn für sie werden 64-Bit-Kernel immer interessanter; gleichzeitig wollen sie den 64-Bit-Overhead möglichst vermeiden, weil die x86-Embedded-CPUs schwachbrüstiger sind als die CPUs heutiger Desktop-PCs und Notebooks.

Entwicklungsstatus

Bereits Ende August hat Greg Kroah-Hartman wie erwartet die Stable- und Longterm-Kernel 3.0.4, 2.6.33.19 und 2.6.32.46 freigegeben. In der Freigabe-Mail zum 33er-Kernel betonte er, diese Kernel-Serie hauptsächlich für die Entwickler des RT-Zweigs zu pflegen. Deren Echtzeit-Kernel basiere derzeit auf 2.6.33, solle aber bald auf Linux 3.0 aufsetzen; Kroah-Hartman deutet an, dann die Pflege der 33er-Serie einzustellen.

Anders als erwartet veröffentlichte Linus Torvalds an diesem Montag keine neue Vorabversion der nächsten Kernel-Version des Hauptentwicklungszweigs . Ohnehin ist die Kernel-Entwicklung nach dem Einbruch bei Kernel.org etwas verlangsamt. Anfangs hatten die Server die dort vorgehaltenen Daten noch ausgeliefert; seit Mitte letzter Woche zeigt Kernel.org allerdings nur noch den Hinweis, es seien Wartungsarbeiten im Gange. Über Kernel.org erreichbare Dinge wie die Fehlerdatenbank, die Wikis und andere Angebote sind daher derzeit nicht verfügbar, was die Entwicklung des Kernels verlangsamt. Zwischenzeitlich gab es auch Schwierigkeiten mit dem DNS, durch die auch Mailinglisten wie die LKML einige Stunden nicht funktionierten.

Mails auf der LKML zeigen, dass Torvalds jetzt zudem genauer darüber nachdenkt, von wo er Änderungen bezieht, die er in den Hauptentwicklungszweig einpflegt. Er betonte in dem Zusammenhang, bestehende Arbeitsweisen nach dem Einbruch bei Kernel.org überdenken zu wollen. Er setze aber viel Vertrauen in persönliche Beziehungen – oft mehr als in technische Lösungen. Schon mit einigen amüsant geschriebenen Hinweisen in der Freigabe-Mail zum Linux 3.1-rc5 hatte Torvalds deutlich zu machen versucht, Anwender sollten nicht jeder Quelle trauen, die Linux-Quellcode oder Patches anbietet.