path: root/es_ES.ISO8859-1/FAQ/hackers.sgml

<!-- $FreeBSD$ -->
<!-- The FreeBSD Documentation Spanish Project -->
  <sect>
    <heading>S&oacute;lo para hackers serios de FreeBSD<label id="hackers">
    </heading>

    <sect1>
      <heading>
        &iquest;Qu&eacute; son SNAPs y RELEASEs?
      </heading>

      <p>Hay actualmente tres ramas activas/semi-activas en el desarrollo de
      FreeBSD y en su
      <url url="http://www.FreeBSD.org/cgi/cvsweb.cgi" name="CVS Repository">:

      <itemize>
        <item><bf/RELENG_2_2/   AKA <bf/2.2-stable/ AKA <bf/"2.2 branch"/
        <item><bf/RELENG_3/   AKA <bf/3.x-stable/ AKA <bf/"3.0 branch"/
        <item><bf/HEAD/         AKA <bf/-current/ AKA <bf/4.0-current/
      </itemize>

      <p><bf/HEAD/ no es una rama actual, como las otras dos, es
      simplemente una constante simb&oacute;lica para <em/la versi&oacute;n 
      de desarrollo actual/ a la cual nos referimos simplemente como 
      <bf/-current/.

      <p>Actualmente, <bf/-current/ es el desarrollo de la versi&oacute;n 4.0 y
      la rama <bf/3.0-stable/ es <bf/RELENG_3/, separada de -current en Enero 
      de 1999.

    <sect1>
      <heading>
        &iquest;C&oacute;mo puedo hacerme mi propia release personalizada?<label id="custrel">
      </heading>

      <p>Para hacer una release necesitas hacer tres cosas: primero,
      necesitas usar un kernel con el driver <htmlurl
      url="http://www.FreeBSD.org/cgi/man.cgi?vn" name="vn"> configurado.
      A&ntilde;ade esto a tu fichero de configuraci&oacute;n del kernel y 
      crea un nuevo kernel:

      <verb>
        pseudo-device vn         #Vnode driver (turns a file into a device)
      </verb>

      <p>Segundo, debes tener las herramientas del CVS a mano. Para hacer
      esto, puedes usar 
      <url url="../../handbook/synching.html#CVSUP" name="CVSUP">
      pero en tu supfile pon el nombre de la release a cvs y borra cualquier
      tag campo de fecha:

      <verb>
        *default prefix=/home/ncvs
        *default base=/a
        *default host=cvsup.FreeBSD.org
        *default release=cvs
        *default delete compress use-rel-suffix

        ## Main Source Tree
        src-all
        src-eBones
        src-secure

        # Other stuff
        ports-all
        www
        doc-all
      </verb>

      <p>A continuaci&oacute;n ejecuta <tt/cvsup -g supfile/ para tener todos 
      los bits correctos en tu ordenador.

      <p>Finalmente, necesitas una buena cantidad de espacio vac&iacute;o para
      crear en el la release. Digamos que est&aacute; en 
      <tt>/algun/disco/grande</tt> y en el ejemplo anterior has dejado los 
      ficheros del CVS en <tt>/home/ncvs</tt>:

      <verb>
        setenv CVSROOT /home/ncvs        # or export CVSROOT=/home/ncvs
        cd /usr/src/release
        make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/algun/disco/grande/release
      </verb>

      <p>Una release completa ser&aacute; creada en 
      <tt>/algun/disco/grande/</tt> y tendr&aacute;s una instalaci&oacute;n 
      completa de tipo FTP en <tt>/algun/disco/grande/R/ftp</tt> cuando acabes.
      Si quieres crear tu SNAP usando otra rama de desarrollo diferente de 
      -current, puedes a&ntilde;adir <tt/RELEASETAG=SOMETAG/ a la l&iacute;nea 
      de comando anterior de creaci&oacute;n de la release. Por ejemplo, 
      <tt/RELEASETAG=RELENG_2_2/ crear&iacute;a un snapshot 2.2 GAMMA.

    <sect1>
      <heading>&iquest;C&oacute;mo creo discos de instalaci&oacute;n personalizados?</heading>

      <p>El proceso completo de creacaci&oacute;n de discos de 
      instalaci&oacute;n y archivos fuentes y binarios esta automatizado por 
      varios targets en <tt>/usr/src/release/Makefile</tt>. La 
      informaci&oacute;n alli contenida deber&iacute;a ser suficiente para que 
      puedas empezar. Falta decir que este proceso necesita la ejecuci&oacute;n
      del comando "make world" y quiz&aacute;s te use mucho tiempo y espacio 
      en disco.

    <sect1>
      <heading>``make world'' destruye mis binarios instalados.</heading>

      <p>S&iacute;, esta es la idea general; como su nombre sugiere, 
      "make world" rehace todos los binarios del sistema, de manera que puedas 
      estar seguro de tener un entorno limpio y consistente al final (que es
      por lo que tarda tanto).

      <p>Si la variable de entorno <tt/DESTDIR/ est&aacute; definida mientras se
      ejecuta <tt/make world/ o <tt/make install/, los binarios creados
      nuevamente seran depositados en un &aacute;rbol de directorios 
      id&eacute;ntico al instalado, y a partir de 
      <tt>&dollar;&lcub;DESTDIR&rcub;</tt>.  Algunas combinaciones aleatorias 
      de modificaciones de librer&iacute;as compartidas y programas pueden 
      causar que falle el <tt/make world/.

    <sect1>
      <heading>
        Cuando mi sistema arranca, dice (bus speed defaulted).
      </heading>

      <p>Las controladoras SCSI Adaptec 1542 permiten al usuario configurar
      su velocidad de acceso al bus en software. Versiones anteriores del
      driver de la 1542 intentaban determinar la velocidad m&aacute;s alta 
      factible y configurar la Adaptec a esta. Nos hemos encontrado con que esto
      hace fallar el sistema de algunos usuarios, por lo que tienes que
      definir la opci&oacute;n de configuraci&oacute;n del kernel
      <tt/TUNE&lowbar;1542/ para que esto ocurra. En algunos sistemas puede
      que puede hacer que los discos vayan m&aacute;s r&aacute;pidos, pero en 
      otros puede que los datos queden corrompidos.


    <sect1>
      <heading>
        &iquest;Puedo seguir la rama current con acceso limitado a Internet?<label id="ctm">
      </heading>

      <p>S&iacute;, puedes hacerlo <tt/sin/ bajarte todo el c&oacute;digo 
      fuente usando la
      utilidad <url url="../../handbook/synching.html#CTM" name="CTM.">

    <sect1>
      <heading>&iquest;C&oacute;mo partir la distribuci&oacute;n en ficheros de 240k?</heading>

      <p>Los sistemas BSD m&aacute;s modernos tienen una opci&oacute;n 
      <tt/-b/ para partir que les permite partir los ficheros en 
      tama&ntilde;os arbitrarios.

      <p>Aqui hay un ejemplo de <tt>/usr/src/Makefile</tt>.

      <verb>
        bin-tarball:
        (cd $&lcub;DISTDIR&rcub;; \
        tar cf - . \
        gzip --no-name -9 -c | \
        split -b 240640 - \
        $&lcub;RELEASEDIR&rcub;/tarballs/bindist/bin_tgz.)
      </verb>

    <sect1>
      <heading>&iquest;He escrito una extensi&oacute;n del kernel, a quien la 
      env&iacute;o?</heading>

      <p>Por favor, mira en <url url="../../handbook/contrib.html"
      name="como enviar c&oacute;digo.">

      <p>Y gracias por pensar en nosotros!

    <sect1>
      <heading>&iquest;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.

    <sect1>
      <heading>&iquest;Soporta 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>
     
      <p>Esto depende de si quieres hacer que el driver est&eacute; 
      p&uacute;blicamente disponible. Si la respuesta es afirmativa, por favor,
      envianos una copia del c&oacute;digo fuente del driver y las 
      modificaciones apropiadas del fichero <tt>files.i386</tt>, un ejemplo de 
      configuraci&oacute;n y el c&oacute;digo apropiado de <htmlurl 
      url="http://www.FreeBSD.org/cgi/man.cgi?MAKEDEV" name="MAKEDEV"> para
      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 notes 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 mayor parte 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>. Esta 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 listado en <tt>src/sys/i386/conf/kernel.script</tt>
      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 compila 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 potencia de 2, pero no estoy totalmente seguro.]

</sect>