Portage de Linux sur une autre plate-forme requise
Je sais que Linux est disponible et a été porté sur de nombreuses plates-formes différentes telles que X86, ARM, PowerPC, etc.
Cependant, en termes de portage, que faut-il exactement?
Ma compréhension est que Linux est un logiciel écrit en C. Par conséquent, lors du portage de Linux à l'origine de X86 vers ARM ou d'autres par exemple, n'est-ce pas seulement une question de recompilation du code avec le compilateur pour l'architecture cible spécifique?
Mis à part les pilotes de périphériques pour différents périphériques, quoi d'autre devrait être fait lors du portage de Linux vers une nouvelle architecture. Le compilateur ne s'occupe-t-il pas de tout pour nous?
Même si la plupart du code du noyau Linux est écrit en C, il existe encore de nombreuses parties de ce code qui sont très spécifiques à la plate-forme sur laquelle il s'exécute et doivent en tenir compte.
Un exemple particulier de cela est la mémoire virtuelle, qui fonctionne de la même manière 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 même augmenté 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 des 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 traités avec du code spécifique à Arch. La plupart d'entre eux impliquent cependant du code en langage assembleur. Voici des exemples:
Commutation 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 de l'ensemble enregistré du processus planifié dans la CPU. Même le nombre et l'ensemble de registres sont très spécifiques à chaque architecture. Ce code est généralement implémenté dans Assembly, pour permettre un accès complet aux registres et également pour garantir qu'il s'exécute aussi rapidement que possible, car les performances de la commutation 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 il se peut que ces instructions ne contiennent pas ces instructions, de sorte que les détails de celles-ci seront toujours uniques.)
Interrupt Handlers: 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 une colle au niveau de l'assembly pour gérer les conventions d'appel spécifiques utilisées pour la plate-forme. De plus, les primitives pour activer/désactiver les interruptions sont généralement spécifiques à la plate-forme et nécessitent également un code d'assembly.
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 d'assembly 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 en ligne d'autres processeurs sont également spécifiques à la plate-forme.
Locking Primitives: L'implémentation de primitives de verrouillage (telles que les verrous tournants) 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 atomiquement (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 du code d'assemblage.
Il existe probablement d'autres domaines dans lesquels un code spécifique à la plate-forme ou à l'architecture est nécessaire dans un noyau (ou, spécifiquement, dans le noyau Linux.) En regardant l'arborescence des sources du noyau, il existe des sous-arbres 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 que 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 y a beaucoup de cas qu'un noyau doit connaître et qui sont spécifiques à une plate-forme. Le noyau Linux essaie d'abstraire la plupart de ceux-ci, donc des algorithmes de niveau supérieur (tels que le fonctionnement de la gestion et de la planification de la mémoire) peuvent être implémentés en C et fonctionner de la même manière (ou presque la même) sur toutes les architectures.
En plus de porter le noyau Linux, vous devrez définir l'interface binaire d'application (ABI) pour "l'espace utilisateur" programmes et portez 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 C, l'assembleur et l'éditeur de liens: GCC et GNU Binutils . Pour une architecture CPU entièrement nouvelle, vous devez porter ce logiciel avant même de commencer à porter le noyau, car le noyau est lui-même un programme C et doit être compilé. S'il existe déjà une prise en charge "back-end" pour le processeur de votre plate-forme, mais pas avec Linux en tant que noyau du système d'exploitation, vous avez beaucoup moins de travail à faire et vous pourrez peut-être vous contenter de reporter la majeure partie du travail jusqu'à ce que le noyau soit en place et fonctionnement.
- La bibliothèque d'exécution C: " GNU libc ". Cette bibliothèque inclut le code qui effectue les appels système et interagit 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 quelques tâches restantes qui nécessite une petite quantité de langage d'assemblage manuscrit.
De nombreux autres logiciels ont des composants optionnels dépendants 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 de processeur , 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 plateforme.
Vous devez informer le noyau du matériel sur lequel vous portez. Le travail du noyau est d'interfacer directement avec le matériel, donc pour qu'il fonctionne correctement, le noyau doit connaître le CPU, les oscillateurs (horloges) et tous les périphériques, comme les différents types de ports série (SPI, CAN, I2C, etc.).
Dans l'ancien temps, vous faisiez cela en écrivant du code spécifique à la plate-forme que les pilotes utilisaient ensuite pour fonctionner. De nos jours, cela se fait en écrivant un définition de l'arborescence des périphériques .