diff --git a/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml index 1ee70eb2ca..f19b39e3bc 100644 --- a/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml +++ b/fr_FR.ISO8859-1/books/handbook/linuxemu/chapter.sgml @@ -3648,8 +3648,182 @@ options SHMMAXPGS=393216 - Advanced Topics ** Traduction en Cours ** - + Sujets avancés + + Si vous êtes curieux de savoir comment la + compatibilité binaire avec Linux fonctionne, cette + section est faite pour vous. La plupart de ce qui suit est + principalement basé sur un courrier électronique + de Terry Lambert tlambert@primenet.com + envoyé à la &a.chat; (Message ID: + <199906020108.SAA07001@usr09.primenet.com>). + + + Comme ça marche? + + chargeur de classe d'exécution + + &os; possède une abstraction appelée + “chargeur de classe d'exécution”. C'est + une portion de l'appel système &man.execve.2;. + + Ce qui se passe est que &os; dispose d'une liste de + chargeurs, à la place d'un simple chargeur avec retour + (“fallback”) vers le chargeur + #! pour exécuter n'importe quel + interpréteur de commandes ou procédure. + + Historiquement, l'unique chargeur sur les plate-formes + &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 &man.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 est celle par défaut quelque + soit l'interpréteur de commandes actuel. + + Plus tard, une modification a été faite sur + &man.sh.1; pour examiner les deux premiers caractères, + et s'ils étaient :\n, alors elle + invoquait l'interpréteur de commandes &man.csh.1; + à la place (nous pensons que l'entreprise SCO fut la + première à faire cette modification). + + Ce que fait maintenant &os; est de parcourir une liste de + chargeurs, avec un chargeur #! + générique qui reconnait les noms des + interpréteurs qui se trouvent après le + caractère espace suivant, puis avec un retour possible + vers /bin/sh. + ELF + + Pour le support de l'ABI Linux, &os; voit le nombre + magique comme un binaire ELF (il ne fait pas la + différence à ce niveau entre &os;, &solaris;, + Linux, ou tout autre système d'exploitation qui dispose + d'un type d'image ELF). + Solaris + + Le chargeur ELF recherche une marque + spécifique, qui se trouve dans une section de commentaire + 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 &man.brandelf.1;: + + &prompt.root; brandelf -t Linux file + + Quand cela est fait, le chargeur ELF verra le marquage + Linux sur le fichier. + + ELF + marquage + + + Lorsque le chargeur ELF voit le marquage + Linux, le chargeur remplace un pointeur + dans la structure proc. Tous les appels + système sont indéxé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 &os;, de d'appel système. + + De plus, le mode Linux redéfinit dynamiquement + l'origine des requêtes; c'est, en effet, ce qu'effectue + l'option (pas le + type de système de fichiers + unionfs!) de montage des systèmes de + fichiers. Tout d'abord, une tentative est faite pour + rechercher le fichier dans le répertoire /compat/linux/chemin-origine, + puis uniquement 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 &os;, s'il n'y a pas + de binaires Linux correspondant présents, et vous + pourriez placer une commande &man.uname.1; dans l'arborescence + /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 &os;; 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 &os; + et Linux: les opérations sur les systèmes de + fichiers, les opérations sur la mémoire + virtuelle, la gestion des signaux, l'IPC System V, etc. La + seule différence est que les binaires &os; utilisent + les fonctions glue de &os;, et les + binaires Linux celles de Linux (les plus anciens + systèmes d'exploitation avaient uniquement leurs + propres fonctions de glue: les adresses + des fonctions dans une structure sysent[] + statique globale, au lieu des adresses des fonctions + déréférencées d'un pointeur + initialisé dynamiquement pointant vers la structure + proc du processus faisant l'appel). + + Laquelle est l'ABI native &os;? Cela n'a pas + d'importance. Basiquement, la seule différence est que + (actuellement, cela pourrait facilement changer dans les + versions futures, et probablement après cela) les + fonctions glue de &os; 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. + + Oui, mais est-ce vraiment de l'émulation? Non. + C'est l'implémentation d'une interface binaire pour les + applications (ABI). Il n'y a pas d'émulateur (ou de + simulateur, pour couper court aux prochaines questions) + impliqué. + + Mais pourquoi appelle-t-on parfois cela + “émulation Linux”? Pour rendre difficile + la vente des versions de &os;! Sérieusement, c'est + dû au fait que l'implémentation historique 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 &os; + exécutait les binaires Linux n'était pas vrai si + vous n'aviez pas compilé le code ou chargé un + module, aussi un terme était nécessaire pour + qualifier ce qui était chargé — donc + l'“émulateur Linux”. +