From e9ed3cf4c8cd5aa1dbd4aeaf1ba082ce08ac9e59 Mon Sep 17 00:00:00 2001
From: Jesus Rodriguez Cuesta <jesusr@FreeBSD.org>
Date: Mon, 29 Mar 1999 18:46:28 +0000
Subject: Include sections:

- Directory policies
- Kernel panics
- dlsym()
- Kernel address space
---
 es/FAQ/hackers.sgml | 375 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 368 insertions(+), 7 deletions(-)

(limited to 'es/FAQ')

diff --git a/es/FAQ/hackers.sgml b/es/FAQ/hackers.sgml
index 9bf1cda47e..11d9bf865f 100644
--- a/es/FAQ/hackers.sgml
+++ b/es/FAQ/hackers.sgml
@@ -1,4 +1,4 @@
-<!-- $Id: hackers.sgml,v 1.5 1999-01-29 19:31:06 jesusr Exp $ -->
+<!-- $Id: hackers.sgml,v 1.6 1999-03-29 18:46:28 jesusr Exp $ -->
 <!-- The FreeBSD Documentation Spanish Project -->
   <sect>
     <heading>S&oacute;lo para hackers serios de FreeBSD<label id="hackers">
@@ -168,13 +168,87 @@
       <p>Y gracias por pensar en nosotros!
 
     <sect1>
-      <heading>Soportar&aacute; FreeBSD otras arquitecturas?</heading>
+      <heading>C&oacute;mo se detectan e inicializan las tarjetas ISA y PnP?</heading>
+
+      <p>Brevemente, hay unos cuantos puertos de entrada/salida a los que
+      todas las tarjetas PnP responden cuando el ordenador pregunta si hay
+      alguien ah&iacute;. As&iacute;, cuando comienza la rutina de prueba
+      de PnP, pregunta si hay alguna tarjeta PnP presente y todas las 
+      tarjetas responden con su n&uacute;mero de modelo a una lectura I/O
+      del mismo puerto. As&iacute; el c&oacute;digo de prueba puede conocer
+      el ID de cada tarjeta (asignado por Microsoft/Intel).
+
+      <p>Los ID's son dos campos de 32 bits (2&circ;64) + 8 bits de 
+      checksum. Los primeros 32 bits son el identificador del fabricante. 
+      No se ha dicho publicamente, pero parece estar asumido que diferentes
+      tipos de tarjeta del mismo fabricante pueden tener diferentes id's de
+      fabricante. La idea de necesitar 32 bits s&oacute;lo para los
+      fabricantes parece un poco excesiva.
+
+      <p>La parte baja de 32 bits son un n&uacute;mero de serie, 
+      direcci&oacute;n ethernet, algo que haga a la tarjeta &uacute;nica. El
+      fabricante no debe producir nunca una segunda tarjeta que tenga los 
+      mismos 32 bits de la parte baja, aunque los 32 bits de la parte alta sean
+      diferentes. As&iacute; puedes tener m&uacute;ltiples tarjetas del mismo
+      tipo en la misma m&aacute;quina y los 64 bits ser&aacute;n &uacute;nicos
+      para cada tarjeta.
+
+      <p>Los grupos de 32 bits nunca pueden ser todos cero. Esto permite
+      mostrar todos los bits no-cero durante la b&uacute;squeda binaria
+      inicial.
+
+      <p>Una vez el sistema ha identificado todos los ID's de las tarjetas
+      presentes, reactivar&aacute;a cada tarjeta, una tras otra (a 
+      trav&eacute;s de los mismos puertos I/O), y encontrar&aacute; los 
+      recursos que cada tarjeta necesita, que opciones de interrupci&oacute;n
+      est&aacute;n disponibles, etc. Se realiza un escaneo sobre todas y cada
+      una de las tarjetas presentes para conocer esta informaci&oacute;n.
+
+      <p>Esta informaci&oacute;n se combina con la informaci&oacute;n de los
+      ficheros ECU del disco y con las BIOS MLB. El soporte PnP de ECU y las
+      BIOS para hardware en el MLB usualmente es sint&eacute;tico, y los
+      perif&eacute;ricos no hacen PnP genuino. De todas maneras, examinando
+      la informaci&oacute;n de la BIOS m&aacute;s la informaci&oacute;n
+      ECU, la rutina de prueba puede causar que los dispositivos que no son
+      PnP puedan evitar a esos dispositivos que el c&oacute;digo de prueba
+      no puede volver a posicionar.
+
+      <p>As&iacute;, los dispositivos PnP son visitados una vez m&aacute;s
+      y se les asigna su I/O, DMA, IRQ, direcciones del mapa de memoria. Los
+      dispositivos aparecer&aacute;n en esas direcciones y permanecer&aacute;n
+      en ellas hasta que se vuelva a reinicializar la m&aacute;quina.
+
+      <p>Todo el proceso se ha simplificado mucho, pero espero que hayas podido
+      hacerte una idea del proceso.
 
-      <p>Diferentes grupos de trabajo nos han expresado su inter&eacute;s en
-      trabajar en el soporte multi-artquitectura para FreeBSD y algunas
-      personas est&aacute;n actualmente trabajando en portar FreeBSD a ALPHA,
-      con la cooperaci&oacute;n de DEC. Para discusiones generales sobre
-      nuevas arquietecturas, usa la lista <tt>&lt;platforms@FreeBSD.ORG&gt;</tt>
+    <sect1>
+      <heading>Soportar FreeBSD arquitecturas diferentes a x86?</heading>
+
+      <p>Diferentes grupos de personas han expresado su inter&eacute;s en
+      trabajar en un port multi-arquitectura de FreeBSD y FreeBSD/AXP
+      (ALPHA) es un ejemplo de ese esfuerzo realizado, ahora disponible en
+      forma de 3.0 SNAPshot release en <url
+      url="ftp://ftp.freebsd.org/pub/FreeBSD/alpha/"
+      name="ftp://ftp.freebsd.org/pub/FreeBSD/alpha">. El port de ALPHA
+      funciona actualmente en diferentes tipos de m&aacute;quinas ALPHA, 
+      entre ellas, AlphaStation, AXPpci, PC164, Miata y Multia. Este port
+      todav&iacute;a no se considera una release completa y no lo ser&aacute;
+      hasta que exista una colecci&oacute;n completa de herramientas de
+      instalaci&oacute;n y una distribuci&oacute;n completa en cdrom para
+      instalaci&oacute;, incluyendo un n&uacute;mero razonable de ports y
+      packages funcionales. FreeBSD/AXP debe considerarse software de 
+      calidad BETA en estos momentos. Para m&aacute;s informaci&oacute;n del
+      proyecto, subscr&iacute;bete a la 
+      <tt>&lt;freebsd-alpha@FreeBSD.ORG&gt;</tt><ref id="mailing"
+      name="lista de correo">.
+
+      Tambi&eacute;n se ha expresado inter&eacute;s en un port de FreeBSD para
+      arquitectura SPARC. Subscr&iacute;bete a 
+      <tt>&lt;freebsd-sparc@FreeBSD.ORG&gt;</tt> <ref id="mailing" 
+      name="la lista"> si est&aacute;s interesado en participar en el proyecto.
+      Para discusiones generales en nuevas arquitecturas, participa en 
+      <ref id="mailing" name="la lista">
+      <tt>&lt;freebsd-platforms@FreeBSD.ORG&gt;</tt>.
 
     <sect1>
       <heading>Necesito un numero de dispositivo para un driver propio</heading>
@@ -188,6 +262,293 @@
       crear cualquier fichero especial que use tu dispositivo. Puedes enviar
       todo lo necesario a <tt>&lt;freebsd-hackers@FreeBSD.ORG&gt;</tt>.
 
+    <sect1>
+      <heading>Alternativas a la pol&iacute;tica de directorios</heading>
+
+      <p>En respuesta a esta pregunta de pol&iacute;ticas alternativas
+      para los directorios, el esquema que est&aacute; actualmente en uso
+      no ha cambiado desde que lo escrib&iacute; en 1983. Escrib&iacute; esa
+      pol&iacute;tica para el sistema de ficheros r&aacute;pido original, y
+      nunca se ha revisado. Trabaja bi&eacute;n manteniendo los grupos de
+      cilindros. Como muchos de vosotros habreis notado, el rendimiento es
+      muy pobre con "find". Muchos sistemas de ficheros son creados desde
+      archivos que fueron creados por una primera b&uacute;squeda en 
+      profundidad (tambi&eacute;n conocido como ftw). Estos directorios 
+      terminan esparcidos a trav&eacute;s de los grupos de cilindros. Si
+      conociesemos el n&uacute;mero total de directorios a crear, la 
+      soluci&oacute;n ser&iacute;a  crear (total / fs_ncg) por grupo de
+      cilindros antes de moverlos. Obviamente, tendriamos que crear 
+      alg&uacute;n tipo de heur&iacute;stica para adivinar este n&uacute;mero.
+      Usando un n&uacute;mero peque&ntilde;o fijo (como puede ser
+      10) har&iacute;a de orden de magnitud. Para diferencial restores de 
+      operaciones normales (cuando el algoritmo actual es probablemente
+      m&aacute;s sensible), podr&iacute;s usar el clustering hasta 10 si
+      fueran todos hechos dentro de una ventana de diez segundos. De cualquier
+      manera, mi conclusi&oacute;n es que este es un &aacute;rea para la
+      experimentaci&oacute;n.</p>
+
+      <p>Kirk McKusick, Septiembre 1998</p>
+
+    <sect1>
+      <heading>Obtener todo lo posible de un "kernel panic"</heading>
+
+      <p>
+      <em>[Esta secci&oacute;n fue extraida de un mensaje escrito por <url
+      url="mailto:wpaul@FreeBSD.ORG" name="Bill Paul"> en la 
+      <ref id="mailing" name="lista"> freebsd-current por <url
+      url="mailto:des@FreeBSD.ORG" name="Dag-Erling Co&iuml;dan
+      Sm&oslash;rgrav">, qui&eacute;n a fijado algunos errores y
+      a&ntilde;adido algunos comentarios entre corchetes]</em>
+
+      <p>
+      <verb>
+From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
+Subject: Re: the fs fun never stops
+To: ben@rosengart.com
+Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
+Cc: current@FreeBSD.ORG
+      </verb>
+
+      <p>
+      <em>[&lt;ben@rosengart.com&gt; envi&oacute; el siguiente panic]</em>
+      <verb>
+> Fatal trap 12: page fault while in kernel mode
+> fault virtual address   = 0x40
+> fault code              = supervisor read, page not present
+> instruction pointer     = 0x8:0xf014a7e5
+                                ^^^^^^^^^^
+> stack pointer           = 0x10:0xf4ed6f24
+> frame pointer           = 0x10:0xf4ed6f28
+> code segment            = base 0x0, limit 0xfffff, type 0x1b
+>                         = DPL 0, pres 1, def32 1, gran 1
+> processor eflags        = interrupt enabled, resume, IOPL = 0
+> current process         = 80 (mount)
+> interrupt mask          =
+> trap number             = 12
+> panic: page fault
+      </verb>
+
+      <p>[Cuando] ves un mensaje como este, no es suficiente con solo
+      reproducirlo y enviarlo. El valor del puntero de instrucciones que
+      he marcado arriba es importante; desafortunadamente, depende de la
+      configuraci&oacute;n. En otras palabras, el valor var&iacute;a 
+      dependiendo de la im&aacute;den de kernel exacta que se use. Si 
+      est&aacute;s usando el kernel GENERIC de uno de los snapshots, entonces
+      es posible que alguien pueda seguir la funci&oacute;n 
+      problem&aacute;tica, pero si est&aacute;s usando un kernel
+      personalizado, entonces solo <em>t&uacute;</em> puedes decirnos donde
+      ha ocurrido el fallo.
+
+      <p>Tendr&iacute;as que hacer lo siguiente:
+
+      <itemize>
+        <item>Anotar el valor del puntero de la instrucci&oacute;n. Ten en
+        cuenta la parte <tt/0x8:/ al inicio no es significante en este caso:
+        es la parte <tt/0xf0xxxxxx/ la que queremos.
+        <item>Cuando el sistema rearranca, haz lo siguiente:
+          <verb>
+% nm /kernel.that.caused.the.panic | grep f0xxxxxx
+          </verb> 
+        donde <tt/f0xxxxxx/ es el valor del puntero de la instrucci&oacute;n.
+        El problema es que no obtendr&aacute;s una b&uacute;squeda exacta ya
+        que los s&iacute;mbolos en la tabla de s&iacute;mbolos del kernel
+        son para los puntos de entrada de las funciones y la direcci&oacute;n
+        del puntero de la instrucci&oacute;n estar&aacute; en alg&uacute;n
+        lugar dentro de una funci&oacute;n, no al principio. Si no obtienes
+        un resultado exacto, omite el &uacute;ltimo d&iacute;gito del valor
+        del puntero de la instrucci&oacute;n e intentalo otra vez, por
+        ejemplo:
+          <verb>
+% nm /kernel.that.caused.the.panic | grep f0xxxxx
+          </verb> 
+        Si esto no da ning&uacute;n resultado, elimina otro d&iacute;gito.
+        Repite la operaci&oacute;n hasta que obtengas alg&uacute;n tipo de
+        salida. El resultado ser&aacute; una lista de posibles funciones
+        que causan el panic. Este no es un sistema muy exacto de 
+        b&uacute;squeda de errores, pero es mejor que nada.
+      </itemize>
+
+      <p>Veo gente que constantemente env&iacute;a mensajes de panics como
+      este, pero raramente veo que alguien se tome el tiempo de buscar 
+      la coincidencia entre el puntero de instrucci&oacute;n y una 
+      funci&oacute;n en la tabla de s&iacute;mbolos del kernel.
+
+      <p>La mejor manera de hacer el seguimiento de la causa de un panic es
+      capturar un "crash dump", usando <tt/gdb(1)/ para hacer una traza del
+      "crash dump". Por supuesto, esto depende de que <tt/gdb(1)/ funcione
+      correctamente en -current, lo que no puedo garantizar (recuerdo que
+      alguien ha comentado que el nuevo <tt/gdb(1)/ en formato ELF no
+      manejaba bi&eacute;n los "dumps" de un crash del kernel; algui&eacute;n
+      deber&iacute;a mirar esto antes de que la 3.0 salga del estado beta).
+
+      <p>En cualquier caso, el m&eacute;todo que normalmente uso es este:
+
+      <itemize>
+        <item>Crear un fichero de configuraci&oacute;n de kernel, opcionalmente
+        a&ntilde;adiendo 'options DDB' si piensas que necesitas el debugger
+        del kernel por alg&uacute;n motivo. (Uso esto principalmente para
+        configurar puntos de salida si sospecho que existe alguna 
+        condici&oacute;n que crea un loop infinito).
+        <item>Usar <tt/config -g KERNELCONFIG/ para crear el directorio
+        de configuraci&oacute;n del kernel.
+        <item><tt>cd /sys/compile/KERNELCONFIG; make</tt>
+        <item>Esperar a que el kernel termine de compilar.
+        <item><tt/cp kernel kernel.debug/
+        <item><tt/strip -d kernel/
+        <item><tt/mv /kernel /kernel.orig/
+        <item><tt>cp kernel /</tt>
+        <item>reboot
+      </itemize> 
+
+      <p><em>[Nota: ahora que los kernels de FreeBSD 3.x son ELF por defecto
+      debes usar <tt/strip -g/ en lugar de <tt/strip -d/. Si por alg&uacute;n
+      motivo tu kernel es a&uacute;n a.out, usa <tt/strip -aout -d/.]</em>
+
+      <p>Ten en cuenta que TU <em/NO/ QUIERES ARRANCAR CON UN KERNEL QUE TIENE
+      TODOS LOS SIMBOLOS DE DEBUG EN EL. Un kernel compilado con <tt/-g/
+      puede llegar facilmente a los 10MB de tama&ntilde;o. No tienes que 
+      arrancar esta im&aacute;n masiva, solo lo necesitas para poder usar
+      despu&eacute;s <tt/gdb(1)/ (<tt/gdb(1)/ quiere la tabla de 
+      s&iacute;mbolos). Al contrario, quieres mantener una copia de la
+      im&aacute;gen completa y crear una segunda im&aacute;gen con los
+      s&iacute;mbolos de debug desactivados usando <tt/strip -d/. Es esta
+      segunda im&aacute;gen la que quieres arrancar.
+
+      <p>Para asegurarte de capturar un "crash dump", necesitas editar el
+      fichero <tt>/etc/rc.conf</tt> y apuntar <tt/dumpdev/ a tu 
+      partici&oacute;n de swap. Esto har&aacute; que el script <tt/rc(8)/ use
+      el comando <tt/dumpon(8)/ para activar los "crash dumps". Tambi&eacute;n
+      puedes ejecutar manualmente <tt/dumpon(8)/. Despu&eacute;s de un panic, 
+      el "crash dump" puede ser recuperado usando <tt/savecore(8)/; si 
+      <tt/dumpdev/ est&aacute; en <tt>/etc/rc.conf</tt>, el script
+      <tt/rc(8)/ ejecutar&aacute; <tt/savecore(8)/ automaticamente y
+      pondr&aacute; el "crash dump" en <tt>/var/crash</tt>.
+
+      <p>NOTA: los "crash dumps" de FreeBSD suelen tener el mismo
+      tama&ntilde;o que la cantidad total de memoria f&iacute;sica del
+      sistema. Esto significa que si tienes 64MB de RAM, obtendr&aacute;s
+      un "crash dump" de 64MB. Debido a esto, tienes que asegurarte de tener
+      suficiente espacio libre en <tt>/var/crash</tt>. Alternativamente puedes
+      ejecutar <tt/savecore(8)/ manualmente y hacer la recuparaci&oacute;n en
+      otro directorio donde tengas m&aacute;s espacio libre. Es posible
+      limitar el tama&ntilde;o del "crash dump" usando <tt/options MAXMEM=(foo)/
+      para indicar la cantidad de memoria que el kernel puede ocupar. Por
+      ejemplo, si tienes 128MB de RAM, puedes limitar el uso de memoria del
+      kernel a 16MB para que el "crash dump" sea de 16MB y no de 128MB.
+
+      <p>Una vez hayas recuperado el "crash dump", puedes obtener una traza
+      del stack con <tt/gdb(1)/ de la manera siguiente:
+
+      <p>
+      <verb>
+% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
+(gdb) where
+      </verb>
+
+      <p>Es posible que aparezcan muchas l&iacute;neas de informaci&oacute;n:
+      es una buena idea usar el comando <tt/script(1)/ para capturarlas
+      todas. Usando la im&aacute;gen del kernel con todos los s&iacute;mbolos
+      de debug deber&iacute; mostrar la l&iacute;nea exacta de c&oacute;digo
+      fuente del kernel donde ha ocurrido el panic. Normalmente, tienes que
+      leer la traza del stack de abajo hacia arriba para poder conocer la 
+      secuencia exacta de eventos que han provocado el crash. Tambi&eacute;n
+      puedes usar <tt/gdb(1)/ para mostrar los contenidos de las diferentes
+      variables o estructuras para examinar el estado del sistema en el 
+      momento del crash.
+
+      <p>Ahora, si eres realmente curioso y tienes un segundo ordenador, 
+      puedes configurar <tt/gdb(1)/ para hacer un debug remoto de manera
+      que puedes usar <tt/gdb(1)/ en un sistema para revisar el kernel
+      de otro sistema, de la misma manera que lo har&iacute;as en la
+      m&aacute;quina local.
+
+      <p><em>[Bill a&ntilde;ade: "Olvid&eacute; mencionar una cosa: si tienes
+      DDB activado, puedes forzar un panic (y un crash dump)  tecleando
+      "panic" en el prompt del ddb. Es posible que el debugger se pare
+      durante la fase del panic. Si esto ocurre, teclea "continue" y el
+      crash dump finalizar&aacute;"]</em>
+
+    <sect1>
+      <heading>dlsym() no funciona con ejecutables ELF!</heading>
+
+      <p>Las herramientas ELF no hacen por defecto que los s&iacute;mbolos
+      definidos en un ejecutable sean visibles por el linker din&aacute;mico.
+      Consecuentemente, <tt/dlsym()/ buscar&aacute; en datos obtenidos desde
+      llamadas a <tt>dlopen(NULL, flags)</tt>, lo que provoca que no se
+      encuentren esos s&iacute;mbolos.
+
+      <p>Si quieres buscar, usando <tt/dlsym()/ s&iacute;mbolos presentes
+      en el ejecutable principal de un proceso, necesitas linkar el
+      ejecutable usando la opci&oacute;n <tt>-export-dynamic</tt> en el 
+      <htmlurl url="http://www.freebsd.org/cgi/man.cgi?ld"
+      name="linkador ELF">.
+
+    <sect1>
+      <heading>Incrementando o reduciendo el espacio de direcciones del 
+      kernel</heading>
+
+      <p>Por defecto, el espacio de direcciones del kernel es de 256MB en
+      FreeBSD 3.x y 1GB en FreeBSD 4.x. Si gestionas un servidor de red
+      muy cargado (por ejemplo, servidores FTP o HTTP con mucho 
+      tr&aacute;fico), es posible que encuentres que 256MB no es
+      suficiente.
+
+      <p>As&iacute; que... como incremento el espacio de direcciones?. Hay
+      dos aspectos a tener en cuenta. Primero, necesitas indicarle al kernel
+      que reserve una parte mayor del espacio de direcciones para &eacute;l
+      mismo. Segundo, ya que el kernel se carga al inicio del espacio de
+      direcciones, necesitas disminuir la direcci&oacute;n de carga.
+
+      <p>El primer aspecto lo solucionamos incrementando el valor de
+      <tt/NKPDE/ en <tt>src/sys/i386/include/pmap.h</tt>. Este es una entrada
+      de ejemplo para 1GB de espacio de direcciones:
+
+      <verb>
+#ifndef NKPDE
+#ifdef SMP
+#define NKPDE                   254     /* addressable number of page tables/pde's */
+#else
+#define NKPDE                   255     /* addressable number of page tables/pde's */
+#endif  /* SMP */
+#endif
+      </verb> 
+
+      <p>Para encontrar el valor correcto de <tt/NKPDE/, divide el espacio de
+      direcciones deseado (en megabytes) por cuatro, despu&eacute;s resta uno
+      por UP y dos por SMP.
+
+      <p>Para solucionar el segundo aspecto, necesitas calcular la 
+      direcci&oacute;n correcta de carga: simplemente resta el tama&ntilde;o
+      del espacio de direcciones (en bytes) de 0x100100000; el resultado
+      es 0xc0100000 para 1GB de espacio de direcciones. Ajusta
+      <tt/LOAD_ADDRESS/ en <tt>src/sys/i386/conf/Makefile.i386</tt> a ese
+      valor; a continuaci&oacute;n pon el contador al inicio de la
+      secci&oacute;n al mismo valor, como sigue:
+
+      <verb>
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+ENTRY(btext)
+SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
+SECTIONS
+{
+  /* Read-only sections, merged into text segment: */
+  . = 0xc0100000 + SIZEOF_HEADERS;
+  .interp     : { *(.interp)    }
+      </verb>
+
+      <p>Reconfigura y compial el kernel. Probablemente tengas problemas con
+      <tt/top(1)/, <tt/ps(1)/ y programas as&iacute;; haciendo un 
+      <tt/make world/ deber&iacute;n solucionarse esos problemas (o una 
+      recompilaci&oacute;n manual de <tt/libkvm/, <tt/ps/ y <tt/top/ 
+      despu&eacute;s de copiar el <tt/pmap.h/ parcheado a 
+      <tt>/usr/include/vm/</tt>.
+
+      <p>NOTA: el tama&ntilde;o del espacio de direcciones debe ser un 
+      m&uacute;ltiplo de cuatro megabytes.
 
+      <p><em>[<url url="mailto:dg@freebsd.org" name="David Greenman">
+      a&ntilde;ade:</em> Pienso que el espacio de direcciones del kernel
+      necesita ser una potenica de 2, pero no estoy totalmente seguro.
 
 </sect>
-- 
cgit v1.3