Obwohl der Großteil des Codes im Linux-Kernel in C geschrieben ist, gibt es immer noch viele Teile dieses Codes, die sehr spezifisch für die Plattform sind, auf der er läuft, und die berücksichtigt werden müssen.
Ein besonderes Beispiel dafür ist der virtuelle Speicher, der auf den meisten Architekturen ähnlich funktioniert (Hierarchie von Seitentabellen), aber spezifische Details für jede Architektur hat (wie die Anzahl der Ebenen in jeder Architektur, und dies hat sogar auf x86 mit zugenommen Einführung neuer größerer Chips.) Der Linux-Kernel-Code führt Makros ein, um das Durchlaufen dieser Hierarchien zu handhaben, die vom Compiler auf Architekturen mit weniger Ebenen von Seitentabellen eliminiert werden können (so dass der Code in C geschrieben ist, aber Details der Architektur berücksichtigt Rücksicht.)
Viele andere Bereiche sind für jede Architektur sehr spezifisch und müssen mit Arch-spezifischem Code behandelt werden. Die meisten davon beinhalten jedoch Code in Assemblersprache. Beispiele sind:
-
Kontextwechsel :Die Kontextumschaltung umfasst das Speichern des Werts aller Register für den Prozess, der umgeschaltet wird, und das Wiederherstellen der Register aus dem gespeicherten Satz des Prozesses, der in der CPU geplant ist. Sogar die Anzahl und der Satz von Registern ist für jede Architektur sehr spezifisch. Dieser Code wird normalerweise in Assembler implementiert, um vollen Zugriff auf die Register zu ermöglichen und auch um sicherzustellen, dass er so schnell wie möglich läuft, da die Leistung des Kontextwechsels für das System kritisch sein kann.
-
Systemaufrufe :Der Mechanismus, durch den Userspace-Code einen Systemaufruf auslösen kann, ist normalerweise architekturspezifisch (und manchmal sogar für das spezifische CPU-Modell, zum Beispiel haben Intel und AMD unterschiedliche Anweisungen dafür eingeführt, älteren CPUs fehlen möglicherweise diese Anweisungen, also Details für diese wird immer noch einzigartig sein.)
-
Interrupt-Handler :Details zur Behandlung von Interrupts (Hardware-Interrupts) sind normalerweise plattformspezifisch und erfordern normalerweise etwas Klebstoff auf Assemblyebene, um die spezifischen Aufrufkonventionen zu handhaben, die für die Plattform verwendet werden. Außerdem sind Primitive zum Aktivieren/Deaktivieren von Interrupts normalerweise plattformspezifisch und erfordern ebenfalls Assembler-Code.
-
Initialisierung Hinweis:Einzelheiten darüber, wie die Initialisierung erfolgen sollte, umfassen normalerweise auch Einzelheiten, die für die Plattform spezifisch sind und häufig einen Assembler-Code erfordern, um den Einstiegspunkt zum Kernel zu handhaben. Auf Plattformen mit mehreren CPUs (SMP) sind Details darüber, wie andere CPUs online gebracht werden, normalerweise ebenfalls plattformspezifisch.
-
Primitive sperren :Die Implementierung von Sperrprimitiven (wie Spinlocks) umfasst normalerweise auch plattformspezifische Details, da einige Architekturen unterschiedliche CPU-Anweisungen bereitstellen (oder bevorzugen), um diese effizient zu implementieren. Einige werden atomare Operationen implementieren, einige werden ein cmpxchg bereitstellen, das atomar testen/aktualisieren kann (aber fehlschlägt, wenn ein anderer Autor zuerst einsteigt), andere werden einen "Sperr"-Modifikator für CPU-Anweisungen enthalten. Dazu gehört häufig auch das Schreiben von Assembler-Code.
Es gibt wahrscheinlich andere Bereiche, in denen plattform- oder architekturspezifischer Code in einem Kernel (oder insbesondere im Linux-Kernel) benötigt wird. Wenn Sie sich den Kernel-Quellbaum ansehen, gibt es architekturspezifische Teilbäume unter arch/ und unter include/arch/ wo Sie weitere Beispiele dafür finden können.
Einige sind tatsächlich überraschend, zum Beispiel werden Sie feststellen, dass die Anzahl der verfügbaren Systemaufrufe auf jeder Architektur unterschiedlich ist und einige Systemaufrufe in einigen Architekturen existieren und in anderen nicht. (Sogar auf x86 unterscheidet sich die Liste der Systemaufrufe zwischen einem 32-Bit- und einem 64-Bit-Kernel.)
Kurz gesagt, es gibt viele plattformspezifische Fälle, die ein Kernel beachten muss. Der Linux-Kernel versucht, die meisten davon zu abstrahieren, sodass Algorithmen auf höherer Ebene (z. B. wie Speicherverwaltung und Scheduling funktionieren) in C implementiert werden können und auf allen Architekturen gleich (oder größtenteils gleich) funktionieren.
Zusätzlich zur Portierung des Linux-Kernels müssen Sie die binäre Anwendungsschnittstelle definieren (ABI) für "User Space"-Programme und portieren die untersten Schichten des User Space-Software-Stacks. Linux wird normalerweise mit Low-Level-User-Space-Komponenten aus dem GNU-Projekt verwendet, von denen die wichtigsten sind:
- Der C-Compiler, Assembler und Linker:GCC und GNU Binutils. Für eine völlig neue CPU-Architektur müssen Sie diese Software portieren, bevor Sie überhaupt mit der Portierung des Kernels beginnen, da der Kernel selbst ein C-Programm ist und kompiliert werden muss. Wenn es bereits "Back-End"-Unterstützung für die CPU Ihrer Plattform gibt, nur nicht mit Linux als Betriebssystemkernel, haben Sie wesentlich weniger Arbeit zu erledigen und können möglicherweise damit durchkommen, den größten Teil der Arbeit zu verschieben, bis der Kernel verfügbar ist und läuft.
- Die C-Laufzeitbibliothek:"GNU libc". Diese Bibliothek enthält den Code, der erstellt Systemaufrufe und interagiert ansonsten direkt mit dem Kernel.
- Die "Foreign Function Interface"-Bibliothek, libffi, die eine wesentliche Komponente vieler Hochsprachen-Interpreter ist und eine der wenigen verbleibenden Aufgaben erfüllt, die benötigt werden eine kleine Menge handgeschriebener Assemblersprache.
Viele andere Softwareteile haben optionale plattformabhängige Komponenten; Beispielsweise wird das Surfen im Internet wesentlich schneller, wenn Sie handoptimierte kryptografische Grundelemente für NSS und OpenSSL für Ihre neue CPU-Architektur und Just-in-Time-Kompilierungs-Backends für IonMonkey und V8 schreiben. Diese sind jedoch nicht unbedingt erforderlich, um eine neue Plattform zu erstellen.