AIX-Toolbox for Linux Applications

Software-Entwickler waren bisher darauf angewiesen, unter Linux entwickelte Programme mühevoll für AIX zu portieren, wenn sie unter diesem Betriebssystem laufen sollten. AIX5L Linux Affinity und die AIX Linux Toolbox sollen die Portierung wesentlich erleichtern.

Nachdem die großen Unix-Hersteller Linux als kommerziell nutzbares Betriebssystem (an-)erkannt haben, bemühen sie sich, ihren eigenen Unix-Varianten einen gewissen Linux-Anstrich zu verpassen. Auch wenn der erste Hype vorbei ist – offenbar ist Linux immer noch hip. Die Ansätze der Unix-Großen sind dabei recht unterschiedlich – dieser Artikel beschäftigt sich mit dem von IBM.

Erinnert sich noch jemand an das Projekt Monterey? Angekündigt im Oktober 1998 sollte Monterey die Inkarnation von AIX auf Intels Itanium werden – als Gemeinschaftsprodukt von IBM, Intel und SCO. Ein Jahr später feierte man das erste Jubiläum [1]. Was dort den Eindruck machte, als ginge es Schlag auf Schlag, zog sich leider ziemlich zäh dahin, denn Itanium-Rechner gibt es bis heute nicht wirklich zu kaufen.

Irgendwann muss IBM die Wartezeit zu lange geworden sein, denn dringend war der Nachfolger für AIX 4.3.3 angesagt, und daher erklärte man das Ziel von Monterey mit AIX 5L im Oktober 2000 für erreicht [2]. Caldera/SCO hält sich damit etwas bedeckt und erklärt AIX 5L als ihr High-End-Betriebssystem oberhalb von Unixware. Compaq hat sich dem Vernehmen nach entschlossen, nach dem Verkauf der Alpha-Technologie sowohl Tru64 als auch AIX 5L auf iA64 anzubieten.

War IBM noch im Jahr 1998 bemüht die bereits erkennbare Bedeutung von Linux offiziell herunterzuspielen und stattdessen vehement auf Monterey zu verweisen, tauchte bereits ein Jahr später Linux als Toolbox für AIX 4.3.3 auf.

Positionierungsprobleme?

IBM tut sich nach wie vor etwas schwer, AIX und Linux widerspruchsfrei gegeneinander zu positionieren. So ist häufig die Rede von der viel gelobten Stabilität von AIX mit Journaling Filesystem – in der Hoffnung, der Zuhörer wüsste nicht, dass es für Linux inzwischen vier (fünf, wenn man Ext3 mitrechnet) journalbasierte Dateisysteme gibt, ebenso wie einen Logical Volume Manager (LVM), der dem LVM von HP/UX fast aufs Haar gleicht und daher vom AIX-LVM nicht allzu weit entfernt ist. Andererseits stehen den wenigen Monaten ReiserFS auf Linux acht oder zehn Jahre JFS auf AIX gegenüber und Linux kann zurzeit beispielsweise nicht mit 24 Prozessoren, 96 GByte RAM oder Dateigrößen von einem Terabyte aufwarten.

Richtig ist, dass Linux in den letzten Jahren einige wesentliche Eigenschaften hinzugewonnen hat, die es für kritische Einsätze befähigen. Was gegenüber AIX noch fehlt, ist eine sinnvoll skalierende Unterstützung für mehr als acht Prozessoren und Dinge wie der AIX-Errorlog, im Zusammenhang damit vereinheitlichte Fehlermeldungen der diversen Kerneltreiber oder eine einheitliche Systemadministrations-Oberfläche à la SMIT. Letzteres ist auch eine Folge der geliebten Freiheit, auch Open Source genannt.

Manchem sind vielleicht noch die Flamewars auf der Kernel-Mailingliste vor etwa zwei, drei Jahren geläufig, in denen Forderungen nach bestimmten Hochverfügbarkeits-Features mit dem Argument abgeschmettert wurden, Marketingaspekte zählten einen (Lieblings-Kraftausdruck hier einsetzen)-Dreck. Zwar kümmern sich heute kommerzielle Anbieter um die Umsetzung diverser Eigenschaften, aber hier kocht auch jeder sein eigenes Süppchen – und nicht immer stehen die Ergebnisse unter der GPL.

Monterey: Fast eine Bauchlandung

Aus der “Major UNIX operating system initiative” ist damit gerade mal die ohnehin erforderliche Nachfolgeversion von AIX geworden. Immerhin – und das ist im Zusammenhang mit Linux so interessant – gilt die Linux-Toolbox für AIX 5L als integraler Bestandteil und steht kostenlos zur Verfügung, wenn auch leider ohne Support [6]. Allerdings können sich Anwender mit Fragen und Bug-Reports an das Linux-Affinity-Team wenden [12].

Der Gedanke von IBM ist klar: Für Linux gibt es bereits massenhaft interessante Anwendungen und wenn es gelingt, Software-Anbietern die PowerPC-Plattform mit einer Linux-Entwicklungsumgebung schmackhaft zu machen, dann werden diese zu einem späteren Zeitpunkt ihre Programme vielleicht ganz nach AIX portieren, wenn sie beispielsweise Eigenheiten von AIX nutzen wollen, die Linux (noch) nicht bietet.

Auf iA64 wäre das sicherlich ähnlich interessant, schließlich lebt IBM immer noch zum größten Teil vom Hardwaregeschäft und den zugehörigen Services. AIX 5L für iA64 wird aber derzeit kaum beworben. Beispiel: In der Pressemitteilung zu AIX 5L [3] kommt iA64 nur am Rande und als Fußnote vor. Und auf der Download-Page [4] fehlt eine ganze Reihe Pakete, beispielsweise die nicht ganz unwichtigen Compiler und die Binutils als Binary für iA64. Einen runden Eindruck macht das jedenfalls nicht. Und auf der Webseite zu xSeries (ehemals Netfinity [5]) findet man auch keinen Hinweis – klar, es gibt noch keine fertigen iA64-Maschinen von IBM.

Abbildungen 1a, 1b: Je nachdem, wie man die MANPATH-Variable einstellt, erscheint bei »man cat« die Manualseite des GNU- oder des AIX-»cat«.

Programmier-Interface statt Emulator

Ungeachtet dieser etwas widersprüchlichen Historie hat IBM mit der Linux-Toolbox ein schönes Produkt abgeliefert, auf dem man sich als Linuxer sofort wohl fühlt. Das wichtigste Merkmal neben der eigentlichen Entwicklungsumgebung mit GCC 2.9.6 ist der Paketmanager RPM, der im AIX-eigenen LPP-Format (Licensed Program Product) zur Verfügung steht und sich daher nahtlos in die LPP-Datenbank einfügt. Alle anderen Pakete stehen allerdings als RPMs bereit und tauchen bei der Ausgabe aller LPPs mit »lslpp -l« mit dem Flag »R« für RPM auf.

Der GCC-Compiler stammt aus dem GNUPro-Toolkit von Cygnus Solutions (jetzt Teil von Red Hat) und trägt die Versionsnummer 2.9-aix43-010414 [13]. Dazu gehört natürlich auch ein Satz Header-Dateien und wenn der GCC als Übersetzer arbeitet, benutzt er fallweise Linux-APIs, AIX-APIs oder angepasste AIX-APIs.

Da Linux und AIX sich in diesem Punkt nicht so furchtbar unterscheiden, waren kaum Anpassungen notwendig. Eine Neu-Übersetzung ist aber immer notwendig; Linux-Binaries für Intel werden damit nicht auf Power-CPUs ablauffähig. Technische und andere Papiere zu Linux Affinity sind über die AIX-5l-Homepage [9] zu finden.

Zwei Welten treffen aufeinander

Aus der Sicht des Nur-Anwenders handelt es sich um zwei völlig getrennte Welten, die auch dadurch gekennzeichnet sind, dass die gesamte Toolbox-Software unter »/opt/freeware« liegt, inklusive Binaries (»/opt/freeware/bin«) und Manpages (»/opt/freeware/man«) und so weiter. Das RPM-LPP »rpm.rte« muss allerdings mindestens in der Version 3.0.5.20 installiert sein – frühere sind inkompatibel.

Die Auswahl der Pakete ist sehr umfangreich – IBM hat inzwischen über 270 vorhandene Pakete getestet und stellt sie auf der Download-Seite [4] samt ihrer Source-RPMs zur Verfügung. Darunter befinden sich zum Beispiel die »fileutils« mit »df«, »dd«, »ls« und anderen mehr. Diese Kommandos kommen also doppelt vor, einmal in »/opt/freeware/bin« als GNU-Variante und unter »/usr/bin« als AIX-Binary.

Nun gut, das ist für erfahrene AIX-Systemverwalter nichts Neues; sie installierten sich schon früher auf ihren Maschinen ihres heterogenen Rechnerzoos massenhaft GNU-Tools – der Kompatibilität wegen. Wer beispielsweise mal mit »make« oder »awk« auf verschiedenen Plattformen zu tun hatte, der hat nach Verrauchen des Zorns sicherlich ganz schnell GNU-»make« und -»awk« installiert. Neu ist aber, dass ein etablierter Hersteller solche Open-Source-Werkzeuge nun offiziell als Produkt anbietet, auch wenn es Perl und Tcl/Tk auf AIX schon lange – wenn auch etwas versteckt – als Teil des Parallel Systems Support Program PSSP auf der RS/6000 SP gegeben hat.

Diese strikte Trennung auf Dateisystemebene bedeutet außerdem, dass sich der Benutzer pro Shell eine reine AIX- oder eine Nahezu-Linux-Umgebung einrichten kann. Setzt man im Shell-Init-File

export PATH=/opt/freeware/bin:$PATH
export MANPATH=/opt/freeware/man:$MANPATH

und arbeitet mit der »bash« statt der »ksh«, hat man eine sehr Linux-ähnliche Kommandozeilenumgebung (Abbildungen 1a und 1b).

Abbildung 2:Das Flag »-D_LINUX_SOURCE_COMPAT« bei der Kompilierung dient der Anpassung an die Linux-Semantik. Das Beispiel stammt aus dem Redbook “Running Linux Applications on AIX” [14].

Desktop: KDE 2.1 oder Gnome 1.2

Nicht zu vergessen sind KDE 2.1 und Gnome 1.2, die ebenfalls Bestandteil der Toolbox sind. Bei der Installation wird der Systemverwalter gefragt, ob er eine dieser Umgebungen als Desktop haben will, und siehe da: Nach den bekannten grünen Bootzeilen erscheint beispielsweise der KDE-Login statt des Motif-basierten CDE.

Genau genommen wird CDE dann gar nicht erst installiert. Setzt man in der »/etc/inittab« als Login-Manager »kdm« statt »dt«, dann kann sich jeder Benutzer nach seinen besonderen Vorlieben einen der installierten Desktops selbst auswählen, ob nun KDE, Gnome oder auch CDE.

Zu erwähnen bleibt, dass es von Hewlett-Packard und Sun vergleichbare Kompatibilitätsumgebungen gibt. HP liefert dabei eine Bibliothek namens »libhplx«, die etwa 200 Linux-kompatible APIs nebst zugehöriger Header-Dateien enthält. Sun setzt hingegen auf ein Application Binary Interface mit dem Tool »lxrun«, das einen Software-Layer zwischen Anwendung und Betriebssystem darstellt und Systemaufrufe zur Laufzeit umsetzt. Das geht so freilich nur auf der Intel-Plattform; auf Sparc steht »lxrun« nicht zur Verfügung.

Allerdings scheinen Sun und HP eher nur auf Gnome als ihren künftigen Desktop zu setzen, während IBM zusätzlich KDE und CDE anbietet. Wir hätten dann wieder einmal unterschiedliche Desktops auf den kommerziellen Unix-Varianten [10]. Die Kompatibilitätsboxen von HP und Sun werden Thema späterer Artikel sein.

XV-Übersetzung nicht trivial

Einige populäre Pakete fehlen unter anderem aus lizenzrechtlichen Gründen, beispielsweise der Shareware-X-Viewer XV. Die Linux-Toolbox sei ein kommerzielles Produkt, war offenbar die Meinung in der Entwicklergruppe, und daher seien Lizenzgebühren zu bezahlen. »lex« und »yacc« fehlen auch, aber dazu später mehr.

In Sachen XV bietet es sich an, das Source-RPM von einer zufällig herumliegenden SuSE-7.0-CD zu nehmen und den Übersetzungslauf mit »rpm -bc xv.spec« anzustoßen. Dabei zeigt sich auch gleich eine Lücke in der sonst sehr umfangreichen und vollständigen Umgebung: »imake« ist auf AIX und Linux Bestandteil der jeweiligen X11-Pakete und gehört daher nicht zur Toolbox.

Der AIX-»imake« ist jedoch der Meinung, dass einige Zeilen des mit XV 3.10a kommenden »Imakefile« Syntaxfehler haben, und bricht ab. Was genau zu dem Fehler geführt hat, war nicht festzustellen, das »Imakefile« sah jedenfalls völlig gesund aus. Bei der Übersetzung von X-basierten Programmen kann das zu einem Stolperstein werden – in diesen Fällen ist es mit dem einfachen Neu-Übersetzen nicht getan, sondern es wird eine vollständige Portierung fällig.

In manchen Fällen kommen Programme wie XV auch mit einem normalen Makefile, für den Fall, dass »xmkmf« und »imake« nicht installiert sind. Im vorliegenden Fall half das aber auch nicht, weil es im Sourcecode und den AIX-Includes diverse Mehrfachdefinitionen beispielsweise für »int32« gibt.

Grund hierfür ist die schon etwas veraltete »libtiff« in XV. Man benutzt besser die aktuellere aus der Toolbox. Hier ist die Einbindung der Linux-Entwicklungsumgebung nicht vollständig – es gibt zwar in einigen AIX-Header-Dateien eine Abfrage

#ifdef _LINUX_SOURCE_COMPAT

aber leider nicht überall, wo es angebracht wäre. Auf diese Weise entsteht bei naiver Vorgehensweise sehr schnell ein gewisses Include-Chaos. Beispielsweise definiert AIX in »/usr/include/sys /m_param.h«

#define hz 100

und darüber stolpert jeder Compiler bei der Übersetzung von »chrono.c« aus der iX-SSBA [7], die »hz« als Variable benutzt. Im Beispiel beschränkt sich die Portierung zwar auf ein einfaches Umbenennen der Variablen im Sourcecode, aber bei größeren Projekten kann das ganz schnell nerven.

Benchmark im Sourcecode

Mangels anderer im Sourcecode verfügbarer Workstation-Benchmarks dient die iX-SSBA [11], hier stellvertretend der Dhrystone, als Hilfsmittel, um die beiden Compiler GCC und AIX Visual Age C-Compiler miteinander zu vergleichen. Von der Effizienz des erzeugten Codes hängt unter anderem auch ab, ob Softwarehersteller überhaupt zu irgendeinem Zeitpunkt zum AIX-Compiler greifen oder es doch bei der Einfach-Portierung mit GCC belassen. Das “IBM pSeries preSales Team” in München hat vor einiger Zeit auf einer Power3-basierten Maschine einen Test mit Povray durchgeführt und als Ergebnis einen ungefähren Performancevorteil von fünf bis sieben Prozent für den AIX-Compiler festgestellt.

Das ist nicht besonders viel – wenn man bedenkt, dass es für den GCC noch kein Power3-Back-End gibt – und bei normalen Anwenderprogrammen kaum spürbar. Erst bei sehr CPU-intensiven, lang laufenden Programmen wie umfangreichen numerischen Berechnungen kommen die Vorteile zum Zug. So bewahrt IBM sich einen Performancevorteil für die native AIX-Umgebung speziell für Serveranwendungen.

Um einigermaßen vergleichbare Ergebnisse zu bekommen, lief die iX-SSBA mit dem AIX-Compiler und dem GCC jeweils mit der Grundoptimierung »-O« sowie mit verschiedenen Architekturschaltern und Tuningoptionen (siehe Kasten “Dhrystone-Messwerte”).

Abbildung 3: Eine solche Maschine vom Typ IBM eServer pSeries 640 (zwei Power3-CPUs mit 375 MHz, 512 MByte RAM) dient zur Leistungsmessung der Compiler.

Compiler vs. Compiler

Mit den angegebenen Compileroptionen lässt sich die SSBA in beiden Welten übersetzen und anstoßen. Da es im Test nicht um Plattenperformance geht, kommt der Festplatten-Benchmark »bonnie« nicht zum Einsatz.

Ein Stolperstein ist die Verwendung von »yacc« und »lex« im Einzeltest für die Tools. Da diese beiden Programme nicht Bestandteil der Toolbox sind, findet der Test immer mit den AIX-eigenen Tools statt. Abhilfe wäre zwar mit einer Anpassung des SSBA-Makefiles denkbar: Ersetzen von »yacc« durch »bison -y« und »lex« durch »flex«. Das aber nur als Hinweis, denn in diesem Test geht es ausschließlich um die Toolbox.

Kaum relevante Unterschiede

Bei der Betrachtung der Messergebnisse fällt auf, dass es bei einem Großteil der Tests kaum relevante Unterschiede gibt. Einige Resultate sind aber trotzdem bemerkenswert: Für den nicht-optimierten Fall ist der Visual-Age-Compiler etwas schneller als GCC. Für die optimierten Versionen ergibt sich das interessante und bisher noch nicht verstandene Phänomen, dass je nach gesetzten Flags GCC entweder ein wenig schneller als CC ist oder völlig daneben liegt, zum Beispiel wenn »-mpower2« spezifiziert wird. Hier ist also noch etwas zu klären, aber als Beobachtung muss man das wohl erst mal hinnehmen.

Interessant ist auch, dass der GCC mit Optimierung und Architekturflag für Power beim Multiprozessor-Dhrystone (MP) gegenüber der Single-CPU-Version stark abfällt (auf durchschnittlich 78 Prozent gegenüber sonst 93 bis 97). Offenbar kommt der GNUpro-Compiler mit der Multiprozessor-Power-Architektur nicht besonders gut zurecht.

Das wäre in der Tat ein Grund, auf Multiprozessor-Umgebungen den AIX-Compiler einzusetzen. Hier wären weitere Untersuchungen angesagt, zum Beispiel: Wie verhält sich ein solches MP-Binary auf Single-CPU-Maschinen.

Unterm Strich unterscheiden sich die beiden Umgebungen jedoch nicht viel – es macht also durchaus Sinn, unter Linux entwickelte Anwendungen mit Augenmaß und der Hilfe der Linux-Toolbox zu übersetzen und Kunden als RPM oder LPP anzubieten. Wenn man außerdem noch bedenkt, dass die Toolbox zwar ohne echte Unterstützung durch den Hersteller IBM, aber dafür kostenlos zu haben ist, dann handelt es sich um einen echten Knüller. (hmi)