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:
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
|
The FreeBSD Spanish Documentation Project
|
||||||
|
|
||||||
%SOURCE% en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
|
%SOURCE% en_US.ISO8859-1/books/handbook/linuxemu/chapter.sgml
|
||||||
%SRCID% 0.0
|
%SRCID% 1.136
|
||||||
|
|
||||||
$FreeBSD$
|
$FreeBSD$
|
||||||
-->
|
-->
|
||||||
|
@ -3556,23 +3556,189 @@ options SHMMAXPGS=393216
|
||||||
<sect1 id="linuxemu-advanced">
|
<sect1 id="linuxemu-advanced">
|
||||||
<title>Temas avanzados</title>
|
<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>
|
<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>
|
</sect2>
|
||||||
-->
|
|
||||||
</sect1>
|
</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