Même si la plupart du code du noyau Linux est écrit en C, de nombreuses parties de ce code sont encore très spécifiques à la plate-forme sur laquelle il s'exécute et doivent en tenir compte.
Un exemple particulier de ceci est la mémoire virtuelle, qui fonctionne de manière similaire sur la plupart des architectures (hiérarchie des tables de pages) mais a des détails spécifiques pour chaque architecture (comme le nombre de niveaux dans chaque architecture, et cela a augmenté même sur x86 avec introduction de nouvelles puces plus grandes.) Le code du noyau Linux introduit des macros pour gérer la traversée de ces hiérarchies qui peuvent être élidées par le compilateur sur les architectures qui ont moins de niveaux de tables de pages (de sorte que le code est écrit en C, mais prend les détails de l'architecture en considération.)
De nombreux autres domaines sont très spécifiques à chaque architecture et doivent être gérés avec un code spécifique à l'architecture. La plupart d'entre eux impliquent cependant du code en langage d'assemblage. Les exemples sont :
-
Changement de contexte :La commutation de contexte implique la sauvegarde de la valeur de tous les registres pour le processus en cours de désactivation et la restauration des registres à partir de l'ensemble sauvegardé du processus planifié dans la CPU. Même le nombre et l'ensemble des registres sont très spécifiques à chaque architecture. Ce code est généralement implémenté en assembleur, pour permettre un accès complet aux registres et également pour s'assurer qu'il s'exécute aussi rapidement que possible, car les performances de changement de contexte peuvent être critiques pour le système.
-
Appels système :Le mécanisme par lequel le code de l'espace utilisateur peut déclencher un appel système est généralement spécifique à l'architecture (et parfois même au modèle de processeur spécifique, par exemple Intel et AMD ont introduit des instructions différentes pour cela, les processeurs plus anciens peuvent ne pas avoir ces instructions, donc des détails pour ceux sera toujours unique.)
-
Gestionnaires d'interruptions :Les détails sur la façon de gérer les interruptions (interruptions matérielles) sont généralement spécifiques à la plate-forme et nécessitent généralement un peu de colle au niveau de l'assemblage pour gérer les conventions d'appel spécifiques utilisées pour la plate-forme. De plus, les primitives d'activation/désactivation des interruptions sont généralement spécifiques à la plate-forme et nécessitent également du code assembleur.
-
Initialisation :Les détails sur la façon dont l'initialisation doit se produire incluent également généralement des détails spécifiques à la plate-forme et nécessitent souvent du code assembleur pour gérer le point d'entrée du noyau. Sur les plates-formes qui ont plusieurs processeurs (SMP), les détails sur la façon de mettre d'autres processeurs en ligne sont généralement également spécifiques à la plate-forme.
-
Verrouillage des primitives :L'implémentation de primitives de verrouillage (telles que les spinlocks) implique généralement également des détails spécifiques à la plate-forme, car certaines architectures fournissent (ou préfèrent) différentes instructions CPU pour les implémenter efficacement. Certains implémenteront des opérations atomiques, certains fourniront un cmpxchg qui peut tester/mettre à jour de manière atomique (mais échouera si un autre écrivain est entré en premier), d'autres incluront un modificateur "lock" aux instructions CPU. Celles-ci impliqueront souvent également l'écriture de code assembleur.
Il existe probablement d'autres domaines où un code spécifique à la plate-forme ou à l'architecture est nécessaire dans un noyau (ou, plus précisément, dans le noyau Linux.) En regardant l'arborescence des sources du noyau, il existe des sous-arborescences spécifiques à l'architecture sous arch/ et sous include/arch/ où vous pouvez trouver plus d'exemples de cela.
Certains sont en fait surprenants, par exemple vous verrez que le nombre d'appels système disponibles sur chaque architecture est distinct et certains appels système existeront dans certaines architectures et pas dans d'autres. (Même sur x86, la liste des appels système diffère entre un noyau 32 bits et un noyau 64 bits.)
En bref, il existe de nombreux cas dont un noyau doit être conscient et qui sont spécifiques à une plate-forme. Le noyau Linux essaie d'abstraire la plupart de ceux-ci, de sorte que des algorithmes de niveau supérieur (tels que le fonctionnement de la gestion de la mémoire et de la planification) peuvent être implémentés en C et fonctionner de la même manière (ou presque de la même manière) sur toutes les architectures.
En plus du portage du noyau Linux, vous devrez définir l'interface binaire de l'application (ABI) pour les programmes "espace utilisateur" et port les couches les plus basses de la pile logicielle de l'espace utilisateur. Linux est généralement utilisé avec des composants d'espace utilisateur de bas niveau du projet GNU, dont les plus critiques sont :
- Le compilateur, l'assembleur et l'éditeur de liens C :GCC et GNU Binutils. Pour une architecture CPU entièrement nouvelle, vous devez porter ce logiciel avant même de commencer à porter le noyau, puisque le noyau est lui-même un programme C et doit être compilé. S'il existe déjà un support "back-end" pour le processeur de votre plate-forme, mais pas avec Linux comme noyau du système d'exploitation, vous avez beaucoup moins de travail à faire et vous pourrez peut-être vous en sortir en reportant la plupart des travaux jusqu'à ce que le noyau soit opérationnel et en cours d'exécution.
- La bibliothèque d'exécution C :"GNU libc". Cette bibliothèque inclut le code qui crée appels système et interagit autrement directement avec le noyau.
- La bibliothèque "interface de fonction étrangère", libffi, qui est un composant essentiel de nombreux interpréteurs de langage de haut niveau, et effectue l'une des rares tâches restantes qui requiert une petite quantité de langage d'assemblage écrit à la main.
De nombreux autres logiciels ont des composants facultatifs dépendant de la plate-forme ; par exemple, la navigation Web sera beaucoup plus rapide si vous écrivez des primitives cryptographiques optimisées à la main pour NSS et OpenSSL pour votre nouvelle architecture CPU, et des back-ends de compilation juste-à-temps pour IonMonkey et V8. Mais ceux-ci ne sont pas essentiels pour mettre en place une nouvelle plate-forme.