Add last section of chapter. We have linuxemu
chapter up to date. Submitted by: Jose A. Accino accino at uma dot es
This commit is contained in:
J. Vicente Carrasco
parent
70f28eb8bd
commit
fcaf7cf9ec
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=33396
1 changed files with 184 additions and 18 deletions
|
|
@ -5,7 +5,7 @@
|
|||
The FreeBSD Spanish Documentation Project
|
||||
|
||||
%SOURCE% en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
|
||||
%SRCID% 0.0
|
||||
%SRCID% 1.136
|
||||
|
||||
$FreeBSD$
|
||||
-->
|
||||
|
|
@ -3556,23 +3556,189 @@ options SHMMAXPGS=393216
|
|||
<sect1 id="linuxemu-advanced">
|
||||
<title>Temas avanzados</title>
|
||||
|
||||
<para>Pendiente de traducción</para>
|
||||
<!--
|
||||
<para>Si siente curiosidad por saber cómo funciona
|
||||
la compatibilidad con Linux esta es la sección que
|
||||
debe leer. La mayor parte de lo que sigue está
|
||||
basado casi en su totalidad en un mensaje enviado por Terry
|
||||
Lambert <email>tlambert@primenet.com</email> a la lista &a.chat;
|
||||
(Message ID: <literal><199906020108.SAA07001@usr09.primenet.com></literal>).</para>
|
||||
|
||||
<sect2>
|
||||
<title>¿Cómo funciona?</title>
|
||||
<indexterm><primary>cargador de clase en
|
||||
ejecución</primary></indexterm>
|
||||
|
||||
<para>&os; dispone de una abstracció denominada
|
||||
<quote>cargador de clase en ejecución</quote>. Esto no
|
||||
es más que un bloque de có:digo incrustado
|
||||
en la llamada &man.execve.2; del sistema.</para>
|
||||
|
||||
<para>Históricamente las plataformas &unix;
|
||||
disponían de un único cargador
|
||||
de binarios, que en última instancia
|
||||
(<emphasis>fallback</emphasis>) recurría
|
||||
al cargador <literal>#!</literal> para ejecutar
|
||||
cualesquiera intérpretes o scripts de la shell. Ese
|
||||
cargador único examinaba el número
|
||||
mágico (generalmente los 4 u 8 primeros bytes
|
||||
del fichero) para ver si era un binario reconocible
|
||||
por el sistema y, en tal caso, invocaba al cargador
|
||||
binario.</para>
|
||||
|
||||
<para>Si no era de tipo binario, la llamada &man.execve.2;
|
||||
devolvía un error y la shell intentaba empezar
|
||||
a ejecutarlo como órdenes shell, tomando por
|
||||
defecto como punto de partida
|
||||
<quote>la shell actual, sea cual sea</quote>.</para>
|
||||
|
||||
<para>Posteriormente se pensó en hacer una
|
||||
modificación de manera que &man.sh.1; examinara
|
||||
los dos primeros caracteres, de modo que si eran
|
||||
<literal>:\n</literal> se llamaba a la shell
|
||||
&man.csh.1; en su lugar (parece ser que en SCO
|
||||
fueron los primeros en utilizar ese truco).</para>
|
||||
|
||||
<para>Lo que ocurre ahora es que &os; dispone de una
|
||||
lista de cargadores, en lugar de uno solo. &os;
|
||||
recorre esa lista de cargadores, con un cargador genérico
|
||||
<literal>#!</literal> que sabe reconocer los
|
||||
intérpretes en base a los caracteres que
|
||||
siguen al siguiente espacio en blanco, con
|
||||
<filename>/bin/sh</filename> como último
|
||||
recurso.</para>
|
||||
|
||||
|
||||
<indexterm><primary>ELF</primary></indexterm>
|
||||
|
||||
<para>Para dar soporte a la ABI
|
||||
(<quote>Application Binary Interface</quote>) de Linux,
|
||||
&os; interpreta el número mágico como un
|
||||
binario ELF (<quote>Executable and Linking
|
||||
Format</quote>): En este punto no hace distinción
|
||||
entre &os;, &solaris;, &linux; o cualquier otro SO que tenga un
|
||||
tipo de imagen ELF.</para>
|
||||
|
||||
<indexterm><primary>Solaris</primary></indexterm>
|
||||
|
||||
<para>El cargador ELF busca entonces una marca
|
||||
(<emphasis>brand</emphasis>) especial, una
|
||||
sección de comentarios en la imagen ELF
|
||||
que no está presente en los binarios ELF de
|
||||
SVR4/&solaris;.</para>
|
||||
|
||||
<para>Para que los binarios de Linux funcionen deben
|
||||
estar marcados con &man.brandelf.1; como tipo
|
||||
<literal>Linux</literal>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>brandelf -t Linux file</userinput></screen>
|
||||
|
||||
<para>Hecho esto el cargador ELF verá la
|
||||
marca <literal>Linux</literal> en el fichero.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>ELF</primary>
|
||||
<secondary>marcado</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>Cuando el cargador ELF ve la marca
|
||||
<literal>Linux</literal> sustituye un puntero en la
|
||||
estructura <literal>proc</literal>. Todas las
|
||||
llamadas del sistema se indexan a través de
|
||||
este puntero (en un sistema &unix; tradicional
|
||||
sería el «array» de estructura
|
||||
<literal>sysent[]</literal> que contiene las llamadas
|
||||
del sistema). Además, el proceso se marca
|
||||
con unos indicadores (<quote>flags</quote>) para que
|
||||
el vector trampa del código de envío
|
||||
señales lo maneje de una forma determinada,
|
||||
así como otros arreglos (menores) que
|
||||
serán utilizados por el módulo Linux
|
||||
del kernel.</para>
|
||||
|
||||
<para>El vector de llamada del sistema Linux contiene,
|
||||
entre otras cosas, una lista de entradas
|
||||
<literal>sysent[]</literal> cuyas direcciones residen
|
||||
en el módulo del kernel.</para>
|
||||
|
||||
<para>Cuando el binario Linux realiza una llamada al
|
||||
sistema, el código trampa extrae el puntero
|
||||
a la función de la llamada del sistema de la estructura
|
||||
<literal>proc</literal>, y así obtiene los puntos de
|
||||
entrada a las llamadas del sistema Linux, no las
|
||||
de &os;.</para>
|
||||
|
||||
<para>Además, el modo Linux cambia la raíz
|
||||
de las búsquedas de una forma dinámica. En
|
||||
efecto, esto es lo que hace la opción
|
||||
<option>union</option> cuando se monta un sistema de ficheros
|
||||
(¡y que <emphasis>no</emphasis> es lo mismo que el
|
||||
sistema de ficheros <literal>unionfs</literal>!). Primero
|
||||
se hace un intento de buscar el fichero en el directorio
|
||||
<filename>/compat/linux/<replaceable>ruta-original</replaceable></filename>
|
||||
y <emphasis>solo después</emphasis>, si lo anterior
|
||||
falla, se repite la búsqueda en el
|
||||
directorio
|
||||
<filename>/<replaceable>ruta-original</replaceable></filename>. Esto
|
||||
permite que se puedan ejecutar binarios que necesitan de
|
||||
otros binarios (por ejemplo las herramientas de
|
||||
programación (<quote>toolchain</quote>) de Linux
|
||||
pueden ejecutarse en su totalidad bajo la ABI de
|
||||
Linux). Esto significa también que los binarios
|
||||
Linux pueden cargar y ejecutar binarios &os; si los binarios
|
||||
Linux equivalentes no se hallan presentes y que se puede poner
|
||||
una orden &man.uname.1; en el árbol de directorios
|
||||
<filename>/compat/linux</filename> para poder estar seguros de
|
||||
que los binarios Linux no puedan decir que no estaban
|
||||
ejecutándose en Linux.</para>
|
||||
|
||||
<para>En efecto, hay un kernel Linux en el kernel
|
||||
&os;; las distintas funciones subyacentes que
|
||||
implementan todos los servicios proporcionados
|
||||
por el kernel son idénticas en ambas, las
|
||||
tablas de entradas de llamadas del sistema en &os; y en
|
||||
Linux: operaciones del sistema de ficheros, operaciones
|
||||
de memoria virtual, envío de señales
|
||||
IPC System V, etc. La única diferencia es que
|
||||
los binarios &os; reciben sus funciones de
|
||||
conexión (<quote><emphasis>glue</emphasis></quote>)
|
||||
y los binarios Linux las suyas (la mayoría de los
|
||||
sistemas operativos más antiguos solo tienen sus
|
||||
propias funciones de conexión:
|
||||
direcciones de funciones en un <quote>array</quote> de
|
||||
estructura <literal>sysent[]</literal> estática y
|
||||
global, en lugar de direcciones de funciones que se extraen
|
||||
a partir de un puntero inicializado dinámicamente
|
||||
en la estructura <literal>proc</literal> del proceso que hace
|
||||
la llamada).</para>
|
||||
|
||||
|
||||
<para>¿Cuál es entonces la ABI nativa de &os;? No
|
||||
importa. Básicamente, la única diferencia
|
||||
es (ahora mismo; esto podría cambiar y probablemente lo
|
||||
hará en una release futura) que las funciones de
|
||||
conexión de &os; están enlazadas
|
||||
estáticamente en el kernel mientras que las de
|
||||
Linux pueden estarlo también estáticamente o
|
||||
se puede acceder a ellas por medio de un módulo
|
||||
del kernel.</para>
|
||||
|
||||
<para>Bien, pero ¿de verdad es esto una
|
||||
emulación? No. Es una implementación ABI, no
|
||||
una emulación. No hay un emulador involucrado (ni
|
||||
un simulador, para adelantarnos a la siguiente
|
||||
pregunta).</para>
|
||||
|
||||
<para>Entonces ¿por qué a veces se le llama
|
||||
<quote>emulación Linux</quote>? ¡Para hacer
|
||||
más difícil el vender &os;! En serio, se
|
||||
debe a que la primera implementación se hizo
|
||||
en un momento en que realmente no había ninguna
|
||||
palabra distinta a esa para describir lo que se estaba
|
||||
haciendo; decir que &os; ejecutaba binarios Linux no era
|
||||
cierto si no se compilaba el código o se cargaba
|
||||
un módulo; hacía falta una forma de
|
||||
describir todo esto y acabamos usando
|
||||
<quote>emulador Linux</quote>.</para>
|
||||
|
||||
</sect2>
|
||||
-->
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-declaration: "../chapter.decl"
|
||||
sgml-indent-data: t
|
||||
sgml-omittag: nil
|
||||
sgml-always-quote-attributes: t
|
||||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||||
End:
|
||||
-->
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue