Cette section décrit comment la
compatibilité binaire avec Linux® fonctionne, et est basée
sur un courrier électronique
de Terry Lambert <tlambert@primenet.com>
envoyé à la liste de diffusion pour la discussion de sujets non-techniques en rapport avec FreeBSD (Message ID:
<199906020108.SAA07001@usr09.primenet.com>
).
FreeBSD possède une abstraction appelée “chargeur de classe d'exécution”. C'est une portion de l'appel système execve(2).
Historiquement, le chargeur UNIX® examinait le nombre magique (généralement les 4 ou 8 premiers octets du fichier) pour voir si c'était un binaire connu par le système, et si c'était le cas, invoquait le chargeur binaire.
Si ce n'était pas le type de binaire du système, l'appel execve(2) retournait un échec, et l'interpréteur de commandes tentait de l'exécuter comme une commande d'interpréteur. Cette hypothèse était celle par défaut « quelque soit l'interpréteur de commandes actuel ».
Plus tard, une modification a été faite sur
sh(1) pour examiner les deux premiers caractères,
et s'ils étaient :\n
, alors elle
invoquait l'interpréteur de commandes csh(1)
à la place.
FreeBSD possède désormais une liste de chargeurs, avec un
chargeur par défaut, #!
, pour exécuter les
interpréteurs ou les procédures de commandes.
Pour le support de l'ABI Linux®, FreeBSD voit le nombre magique comme un binaire ELF. Le chargeur ELF recherche une marque spécifique, qui se trouve dans une section de commentaires dans l'image ELF, et qui n'est pas présente dans les binaires SVR4/Solaris™ ELF.
Pour que les binaires Linux® puissent fonctionner, ils
doivent être marqués sous le
type Linux
avec brandelf(1):
#
brandelf -t Linux file
Lorsque le chargeur ELF voit le marquage
Linux
, le chargeur remplace un pointeur
dans la structure proc
. Tous les appels
système sont indexés par
l'intermédiaire de ce pointeur (dans un système
UNIX® traditionnel, cela serait la structure
sysent[]
, contenant les appels
système). De plus, le processus est marqué pour
une gestion spéciale du vecteur d'interruption
(“trap”) pour le signal de code
“trampoline”, et plusieurs autres corrections
(mineures) qui sont gérées par le noyau
Linux®.
Le vecteur d'appel système Linux® contient, entre
autres, une liste des entrées
sysent[]
dont les adresses résident
dans le noyau.
Quand un appel système est effectué par le
binaire Linux, le code “trap”
déréférence de la structure
proc
le pointeur de la fonction de l'appel
système, et utilise les points d'entrée Linux®,
et non pas FreeBSD, de d'appel système.
Le mode Linux® redéfinit dynamiquement
l'origine des requêtes. C'est, en effet, équivalent à
l'option union
de montage des systèmes de
fichiers. Tout d'abord, une tentative est faite pour
rechercher le fichier dans le répertoire /compat/linux/
.
Si cela échoue, la
recherche est effectuée dans le répertoire
chemin-origine
/
.
Cela permet de s'assurer que les binaires nécessitant
d'autres binaires puissent s'exécuter. Par exemple,
l'ensemble des outils Linux® peuvent tourner sous l'ABI Linux®.
Cela signifie également que les binaires Linux® peuvent
charger et exécuter les binaires FreeBSD, s'il n'y a pas
de binaires Linux® correspondant présents, et vous
pourriez placer une commande uname(1) dans l'arborescence
chemin-origine
/compat/linux
pour vous
assurer que les binaires Linux® ne puissent pas dire qu'ils ne
tournent pas sous Linux®.
En effet, il y a un noyau Linux® dans le noyau FreeBSD. Les diverses fonctions sous-jacentes qui implémentent tous les services fournis par le noyau sont identiques entre les deux tables d'entrées des appels systèmes FreeBSD et Linux®: les opérations sur les systèmes de fichiers, les opérations sur la mémoire virtuelle, la gestion des signaux, iet l'IPC System V. La seule différence est que les binaires FreeBSD utilisent les fonctions glue de FreeBSD, et les binaires Linux® celles de Linux®. Les fonctions glue de FreeBSD sont liées en statique dans le noyau, les fonctions glue Linux® peuvent être liées statiquement, ou l'on peut y accéder via un module du noyau.
Techniquement, ce n'est pas vraiment de l'émulation, c'est l'implémentation d'une interface binaire pour les applications (ABI). Cela est parfois appelé « émulation Linux® » parce que l'implémentation a été faite à une époque où il n'y avait pas vraiment d'autres mots pour décrire ce qui était en développement. Dire que FreeBSD exécutait les binaires Linux® n'était pas vrai, jusqu'à ce le code de support Linux® soit compilé ou le module soit chargé.
Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Pour toutes questions à propos de FreeBSD, lisez la
documentation avant de contacter
<questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez
<doc@FreeBSD.org>.