Der Aufbruch in eine neue Ära - Athlon 64 im Test
Die liebe Portierung...
Viele der gängigen GNU-Tools wurden bereits an die x86-64-Architektur angepaßt und verrichten ihren Dienst anstandslos. Es ist durchaus verständlich, dass vor allem die Default-Compiler eine Reihe von Änderungen durchliefen und durch zusätzliche Flags in die Lage versetzt werden müssen, sowohl 32- als auch 64-bittigen Code zu erstellen. Zu den vielen Programmen, die in zwei verschiedenen Modi unter der x86-64-Architektur ihre Arbeit verrichten, dürften unter anderem der GNU Assembler as, die Standard-Compiler gcc, g++ und g77, der Linker ld und Applikationen wie gdb, ar, nm, strace und ltrace zählen. Die Umschaltung zwischen den zwei Modi erfolgt anhand diverser Flags (as, gcc, g++...) oder durch den Aufruf einer alternativen 32-bit-Anwendung (strace > strace32, gdb > gdb32...).
Natürlich müssen auch Programmierer die gängigen Richtlinien der 64-bit-Programmierung beachten. Bei unserem Test stellte sich heraus, dass diese Tatsache noch nicht jedem bekannt ist und viele Anwendungen vor allem in der configure-Phase die Endian-Architektur nicht korrekt oder gar nicht erkennen konnten. Ferner sind bei manch einer Anwendung die Prototypen nicht richtig gesetzt, was einfach durch die Tatsache zu erklären ist, dass manche Applikationen die falschen glibc-Header inkludieren. Wenn die Funktion als Beispiel stdargs oder varargs nutzt, erwartet sie von dem %al-Register FP-Argumente. Bei falschen Prototypen ohne die Anbindung von ellipsis wird %al nicht initialisiert und die Anwendung stürzt ab. Dies sind nur einige der Probleme, die den Einsatz unter einer 64-bit-Architektur erschweren können.
Eine weitere (alte) Neuerung gegenüber der i386-Architektur stellt das Compilieren von Bibliotheken dar. Tolerierte die alte Architektur noch Bibliotheken, die ohne -fPIC übersetzt wurden, bestrafen die 64-Bitter alle Programmierer, die dies nicht berücksichtigt haben, mit Abstürzen. SuSE teilt aus diesem Grund die Bibliotheken in zwei Lager - 64-bit-Bibliotheken finden ihren Platz unter */lib64 und 32-bit-Bibliotheken unter */lib. Hier finden Sie Informationen und eine Auflistung des Verzeichnisses /lib eines 32-Bit-Systems. Zum Vergleich dasselbe einschließlich des /lib64-Verzeichnisses auf einem Athlon64-System.
){kind=small}
demon (Mirko Lindner)
Eine leichte und verständliche Konfiguration
... und der Kernel?
Die Nutzer von AMD Athlon 64 finden in der erweiterten Kernel-Version einen weiteren Eintrag unter dem Menü der Prozessor-Auswahl und weitere Funktionen, die viele prozessorspezifische Eigenschaften beeinflussen können. Die Compilierung des Kernels stellt sich, im Gegensatz zu der IA-64-Architektur, identisch mit der unter einer i386-Architektur dar. Ein einfaches »make dep clean bzImage modules modules_install« übersetzt den Kernel und installiert die Module. Durch einen Verzicht auf EFI, welches bei der IA-64-Architektur den BIOS ersetzt und durch eine größere Funktion auffällt, ist auch die Installation des Boot-Loaders mit der unter einer i386-Plattform gleich.
Natürlich sollten auch Treiber und Kernel-Module die typischen Funktionen des Kernels beachten. Daß dem nicht immer so ist, zeigt sich immer aufs Neue, wenn Kernel-Module wegen grober Fehler im Code abstürzen oder sich nicht compilieren lassen. So müssen alle Interrupt-Flags in save_flags() oder spin_lock_irqsave() als unsigned long deklariert sein. Wurde die long-Variante noch unter i386 toleriert, funktioniert es unter einer 64-bit-Architektur nicht mehr. Treiber sollten zudem die PCI DMA mapping API benutzen (mehr Informationen finden alle Interessenten im Kernel-Tree unter Documentation/DMA-mapping.txt). Module, die außerhalb des Kernel-Trees gebaut wurden, müssen ab sofort das Flag -mcmodel=kernel benutzen. Eine Missachtung dieser Anforderung führt bereits nach dem Laden des Moduls zu einem Absturz des Systems. Module, die im Kernel-Tree gebaut worden sind, wurden bereits mit diesem Flag compiliert.
Linux unter Hammer - Die Akte SuSE
Sowohl die Installation als auch die Konfiguration des Systems stellte bei der SuSE-Distribution keine Probleme dar. Die Hardware-Erkennung band alle Komponenten des Test-Systems sauber ein und konfigurierte alle eingebauten Geräte anstandslos. Nach knapp einer halben Stunde stand das System dem Nutzer zur Verfügung. Dabei stellt sich die Installation in keiner Weise anders als die auf einer IA-32-Architektur dar. Wüßten wir es nicht besser (und schauten später auf unserem System nicht nach), würden wir denken, dass SuSE eine Professional-Version von »SuSE 8.1« ausliefert. Ferner konnten wir während unserer fast dreiwöchigen Nutzung des Systems zu keinem Zeitpunkt ein Absturz beobachten. Eine rundum stabile Distribution - und das wohlgemerkt in einer Beta-Version.
Lediglich kleinere Fehler störten ab und an das Vergnügen der Arbeit. So kann es passieren, dass bei einer Umschaltung zwischen dem X-Server und der Konsole bei einer nochmaligen Rückkehr zum X-Server der Mauszeiger nicht mehr benutzbar war. Eine nochmalige Umschaltung auf die Console (CTRL+F1) und ein Wechsel auf die X-Oberfläche schaffen hier Abhilfe. Ferner schien das Konfig-Programm die Tastatur nicht korrekt anzusprechen, wenn beim Booten keine PS/2-Maus angeschlossen wurde. Dieses Phänomen konnte allerdings nur im X-Modus beobachtet werden. Startete der Server ohne X, war auch ein Betrieb ohne Maus möglich.
