Add last section of chapter. We have linuxemu

chapter up to date.

Submitted by: Jose A. Accino accino at uma dot es

1 files changed, 184 insertions, 18 deletions

diff --git a/es_ES.ISO8859-1/books/handbook/linuxemu/chapter.sgml b/es_ES.ISO8859-1/books/handbook/linuxemu/chapter.sgml
index 3f67429f55..f577619306 100755
--- a/es_ES.ISO8859-1/books/handbook/linuxemu/chapter.sgml
+++ b/es_ES.ISO8859-1/books/handbook/linuxemu/chapter.sgml
@@ -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&oacute;n</para>
-    <!--
+    <para>Si siente curiosidad por saber c&oacute;mo funciona
+      la compatibilidad con Linux esta es la secci&oacute;n que
+      debe leer.  La mayor parte de lo que sigue est&aacute;
+      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>&lt;199906020108.SAA07001@usr09.primenet.com&gt;</literal>).</para>
+
     <sect2>
-    </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:
--->
+      <title>&iquest;C&oacute;mo funciona?</title>
+      <indexterm><primary>cargador de clase en
+        ejecuci&oacute;n</primary></indexterm>
+
+    <para>&os; dispone de una abstracci&oacute; denominada
+      <quote>cargador de clase en ejecuci&oacute;n</quote>.  Esto no
+      es m&aacute;s que un bloque de c&oacute:digo incrustado
+      en la llamada &man.execve.2; del sistema.</para>
+
+    <para>Hist&oacute;ricamente las plataformas &unix;
+      dispon&iacute;an de un &uacute;nico cargador
+      de binarios, que en &uacute;ltima instancia
+      (<emphasis>fallback</emphasis>) recurr&iacute;a
+      al cargador <literal>#!</literal> para ejecutar
+      cualesquiera int&eacute;rpretes o scripts de la shell. Ese
+      cargador &uacute;nico examinaba el n&uacute;mero
+      m&aacute;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&iacute;a un error y la shell intentaba empezar
+      a ejecutarlo como &oacute;rdenes shell, tomando por
+      defecto como punto de partida
+      <quote>la shell actual, sea cual sea</quote>.</para>
+
+    <para>Posteriormente se pens&oacute; en hacer una
+      modificaci&oacute;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&eacute;rico
+        <literal>#!</literal> que sabe reconocer los
+	int&eacute;rpretes en base a los caracteres que
+        siguen al siguiente espacio en blanco, con
+	<filename>/bin/sh</filename> como &uacute;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&uacute;mero m&aacute;gico como un
+      binario ELF (<quote>Executable and Linking
+      Format</quote>): En este punto no hace distinci&oacute;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&oacute;n de comentarios en la imagen ELF
+      que no est&aacute; 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&aacute; 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&eacute;s de
+      este puntero (en un sistema &unix; tradicional
+      ser&iacute;a el &laquo;array&raquo; de estructura
+      <literal>sysent[]</literal> que contiene las llamadas
+      del sistema).  Adem&aacute;s, el proceso se marca
+      con unos indicadores (<quote>flags</quote>) para que
+      el vector trampa del c&oacute;digo de env&iacute;o
+      se&ntilde;ales lo maneje de una forma determinada,
+      as&iacute; como otros arreglos (menores) que
+      ser&aacute;n utilizados por el m&oacute;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&oacute;dulo del kernel.</para>
+
+    <para>Cuando el binario Linux realiza una llamada al
+      sistema, el c&oacute;digo trampa extrae el puntero
+      a la funci&oacute;n de la llamada del sistema de la estructura
+      <literal>proc</literal>, y as&iacute; obtiene los puntos de
+      entrada a las llamadas del sistema Linux, no las
+      de &os;.</para>
+
+    <para>Adem&aacute;s, el modo Linux cambia la ra&iacute;z
+      de las b&uacute;squedas de una forma din&aacute;mica. En
+      efecto, esto es lo que hace la opci&oacute;n
+      <option>union</option> cuando se monta un sistema de ficheros
+      (&iexcl;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&eacute;s</emphasis>, si lo anterior
+      falla, se repite la b&uacute;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&oacute;n (<quote>toolchain</quote>) de Linux
+      pueden ejecutarse en su totalidad bajo la ABI de
+      Linux). Esto significa tambi&eacute;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 &aacute;rbol de directorios
+      <filename>/compat/linux</filename> para poder estar seguros de
+      que los binarios Linux no puedan decir que no estaban
+      ejecut&aacute;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&eacute;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&iacute;o de se&ntilde;ales
+       IPC System V, etc.  La &uacute;nica diferencia es que
+       los binarios &os; reciben sus funciones de
+       conexi&oacute;n (<quote><emphasis>glue</emphasis></quote>)
+       y los binarios Linux las suyas (la mayor&iacute;a de los
+       sistemas operativos m&aacute;s antiguos solo tienen sus
+       propias funciones de conexi&oacute;n:
+       direcciones de funciones en un <quote>array</quote> de
+       estructura <literal>sysent[]</literal> est&aacute;tica y
+       global, en lugar de direcciones de funciones que se extraen
+       a partir de un puntero inicializado din&aacute;micamente
+       en la estructura <literal>proc</literal> del proceso que hace
+       la llamada).</para>
+
+
+    <para>&iquest;Cu&aacute;l es entonces la ABI nativa de &os;?  No
+      importa. B&aacute;sicamente, la &uacute;nica diferencia
+      es (ahora mismo; esto podr&iacute;a cambiar y probablemente lo
+      har&aacute; en una release futura) que las funciones de
+      conexi&oacute;n de &os; est&aacute;n enlazadas
+      est&aacute;ticamente en el kernel mientras que las de
+      Linux pueden estarlo tambi&eacute;n est&aacute;ticamente o
+      se puede acceder a ellas por medio de un m&oacute;dulo
+      del kernel.</para>
+
+    <para>Bien, pero &iquest;de verdad es esto una
+      emulaci&oacute;n?  No.  Es una implementaci&oacute;n ABI, no
+      una emulaci&oacute;n. No hay un emulador involucrado (ni
+      un simulador, para adelantarnos a la siguiente
+      pregunta).</para>
+
+    <para>Entonces &iquest;por qu&eacute; a veces se le llama
+      <quote>emulaci&oacute;n Linux</quote>?  &iexcl;Para hacer
+      m&aacute;s dif&iacute;cil el vender &os;!  En serio, se
+      debe a que la primera implementaci&oacute;n se hizo
+      en un momento en que realmente no hab&iacute;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&oacute;digo o se cargaba
+      un m&oacute;dulo; hac&iacute;a falta una forma de
+      describir todo esto y acabamos usando
+      <quote>emulador Linux</quote>.</para>
 
+    </sect2>
+  </sect1>