Add a new translated section "Advanced Topics".
This commit is contained in:
parent
8f608f949f
commit
5751e78660
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=18549
1 changed files with 176 additions and 2 deletions
|
@ -3648,8 +3648,182 @@ options SHMMAXPGS=393216
|
|||
</sect1>
|
||||
|
||||
<sect1 id="linuxemu-advanced">
|
||||
<title>Advanced Topics ** Traduction en Cours **</title>
|
||||
<para></para>
|
||||
<title>Sujets avancés</title>
|
||||
|
||||
<para>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 <email>tlambert@primenet.com</email>
|
||||
envoyé à la &a.chat; (Message ID:
|
||||
<literal><199906020108.SAA07001@usr09.primenet.com></literal>).</para>
|
||||
|
||||
<sect2>
|
||||
<title>Comme ça marche?</title>
|
||||
|
||||
<indexterm><primary>chargeur de classe d'exécution</primary></indexterm>
|
||||
|
||||
<para>&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;.</para>
|
||||
|
||||
<para>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
|
||||
<literal>#!</literal> pour exécuter n'importe quel
|
||||
interpréteur de commandes ou procédure.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para>Cette hypothèse est celle par défaut quelque
|
||||
soit l'interpréteur de commandes actuel.</para>
|
||||
|
||||
<para>Plus tard, une modification a été faite sur
|
||||
&man.sh.1; pour examiner les deux premiers caractères,
|
||||
et s'ils étaient <literal>:\n</literal>, 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).</para>
|
||||
|
||||
<para>Ce que fait maintenant &os; est de parcourir une liste de
|
||||
chargeurs, avec un chargeur <literal>#!</literal>
|
||||
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 <filename>/bin/sh</filename>.</para>
|
||||
<indexterm><primary>ELF</primary></indexterm>
|
||||
|
||||
<para>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).</para>
|
||||
<indexterm><primary>Solaris</primary></indexterm>
|
||||
|
||||
<para>Le chargeur ELF recherche une <emphasis>marque</emphasis>
|
||||
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.</para>
|
||||
|
||||
<para>Pour que les binaires Linux puissent fonctionner, ils
|
||||
doivent être <emphasis>marqués</emphasis> sous le
|
||||
type <literal>Linux</literal> avec &man.brandelf.1;:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>brandelf -t Linux file</userinput></screen>
|
||||
|
||||
<para>Quand cela est fait, le chargeur ELF verra le marquage
|
||||
<literal>Linux</literal> sur le fichier.</para>
|
||||
<indexterm>
|
||||
<primary>ELF</primary>
|
||||
<secondary>marquage</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Lorsque le chargeur ELF voit le marquage
|
||||
<literal>Linux</literal>, le chargeur remplace un pointeur
|
||||
dans la structure <literal>proc</literal>. 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
|
||||
<literal>sysent[]</literal>, 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.</para>
|
||||
|
||||
<para>Le vecteur d'appel système Linux contient, entre
|
||||
autres, une liste des entrées
|
||||
<literal>sysent[]</literal> dont les adresses résident
|
||||
dans le noyau.</para>
|
||||
|
||||
<para>Quand un appel système est effectué par le
|
||||
binaire Linux, le code “trap”
|
||||
déréférence de la structure
|
||||
<literal>proc</literal> 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.</para>
|
||||
|
||||
<para>De plus, le mode Linux redéfinit dynamiquement
|
||||
l'origine des requêtes; c'est, en effet, ce qu'effectue
|
||||
l'option <option>union</option> (<emphasis>pas</emphasis> le
|
||||
type de système de fichiers
|
||||
<literal>unionfs</literal>!) de montage des systèmes de
|
||||
fichiers. Tout d'abord, une tentative est faite pour
|
||||
rechercher le fichier dans le répertoire <filename
|
||||
role='directory'>/compat/linux/<replaceable>chemin-origine</replaceable></filename>,
|
||||
<emphasis>puis</emphasis> uniquement si cela échoue, la
|
||||
recherche est effectuée dans le répertoire
|
||||
<filename
|
||||
role='directory'>/<replaceable>chemin-origine</replaceable></filename>.
|
||||
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
|
||||
<filename role='directory'>/compat/linux</filename> pour vous
|
||||
assurer que les binaires Linux ne puissent pas dire qu'ils ne
|
||||
tournent pas sous Linux.</para>
|
||||
|
||||
<para>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 <emphasis>glue</emphasis> de &os;, et les
|
||||
binaires Linux celles de Linux (les plus anciens
|
||||
systèmes d'exploitation avaient uniquement leurs
|
||||
propres fonctions de <emphasis>glue</emphasis>: les adresses
|
||||
des fonctions dans une structure <literal>sysent[]</literal>
|
||||
statique globale, au lieu des adresses des fonctions
|
||||
déréférencées d'un pointeur
|
||||
initialisé dynamiquement pointant vers la structure
|
||||
<literal>proc</literal> du processus faisant l'appel).</para>
|
||||
|
||||
<para>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 <emphasis>glue</emphasis> de &os; sont liées
|
||||
en statique dans le noyau, les fonctions
|
||||
<emphasis>glue</emphasis> Linux peuvent être
|
||||
liées statiquement, ou l'on peut y accéder via
|
||||
un module du noyau.</para>
|
||||
|
||||
<para>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é.</para>
|
||||
|
||||
<para>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”.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
|
Loading…
Reference in a new issue