From fcaf7cf9ecf999a725bc5742ba50d744e97b9f1e Mon Sep 17 00:00:00 2001 From: "J. Vicente Carrasco" Date: Mon, 8 Dec 2008 23:37:41 +0000 Subject: Add last section of chapter. We have linuxemu chapter up to date. Submitted by: Jose A. Accino accino at uma dot es --- .../books/handbook/linuxemu/chapter.sgml | 202 +++++++++++++++++++-- 1 file changed, 184 insertions(+), 18 deletions(-) (limited to 'es_ES.ISO8859-1/books') 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 Temas avanzados - Pendiente de traducción - - - - - + ¿Cómo funciona? + cargador de clase en + ejecución + + &os; dispone de una abstracció denominada + cargador de clase en ejecución. Esto no + es más que un bloque de có:digo incrustado + en la llamada &man.execve.2; del sistema. + + Históricamente las plataformas &unix; + disponían de un único cargador + de binarios, que en última instancia + (fallback) recurría + al cargador #! 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. + + 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 + la shell actual, sea cual sea. + + Posteriormente se pensó en hacer una + modificación de manera que &man.sh.1; examinara + los dos primeros caracteres, de modo que si eran + :\n se llamaba a la shell + &man.csh.1; en su lugar (parece ser que en SCO + fueron los primeros en utilizar ese truco). + + 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 + #! que sabe reconocer los + intérpretes en base a los caracteres que + siguen al siguiente espacio en blanco, con + /bin/sh como último + recurso. + + + ELF + + Para dar soporte a la ABI + (Application Binary Interface) de Linux, + &os; interpreta el número mágico como un + binario ELF (Executable and Linking + Format): En este punto no hace distinción + entre &os;, &solaris;, &linux; o cualquier otro SO que tenga un + tipo de imagen ELF. + + Solaris + + El cargador ELF busca entonces una marca + (brand) especial, una + sección de comentarios en la imagen ELF + que no está presente en los binarios ELF de + SVR4/&solaris;. + + Para que los binarios de Linux funcionen deben + estar marcados con &man.brandelf.1; como tipo + Linux: + + &prompt.root; brandelf -t Linux file + + Hecho esto el cargador ELF verá la + marca Linux en el fichero. + + ELF + marcado + + + Cuando el cargador ELF ve la marca + Linux sustituye un puntero en la + estructura proc. Todas las + llamadas del sistema se indexan a través de + este puntero (en un sistema &unix; tradicional + sería el «array» de estructura + sysent[] que contiene las llamadas + del sistema). Además, el proceso se marca + con unos indicadores (flags) 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. + + El vector de llamada del sistema Linux contiene, + entre otras cosas, una lista de entradas + sysent[] cuyas direcciones residen + en el módulo del kernel. + + 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 + proc, y así obtiene los puntos de + entrada a las llamadas del sistema Linux, no las + de &os;. + + 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 + cuando se monta un sistema de ficheros + (¡y que no es lo mismo que el + sistema de ficheros unionfs!). Primero + se hace un intento de buscar el fichero en el directorio + /compat/linux/ruta-original + y solo después, si lo anterior + falla, se repite la búsqueda en el + directorio + /ruta-original. Esto + permite que se puedan ejecutar binarios que necesitan de + otros binarios (por ejemplo las herramientas de + programación (toolchain) 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 + /compat/linux para poder estar seguros de + que los binarios Linux no puedan decir que no estaban + ejecutándose en Linux. + + 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 (glue) + 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 array de + estructura sysent[] estática y + global, en lugar de direcciones de funciones que se extraen + a partir de un puntero inicializado dinámicamente + en la estructura proc del proceso que hace + la llamada). + + + ¿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. + + 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). + + Entonces ¿por qué a veces se le llama + emulación Linux? ¡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 + emulador Linux. + + -- cgit v1.2.3