556 lines
26 KiB
Text
556 lines
26 KiB
Text
<!-- $FreeBSD$ -->
|
|
<!-- The FreeBSD Documentation Spanish Project -->
|
|
<sect>
|
|
<heading>Sólo para hackers serios de FreeBSD<label id="hackers">
|
|
</heading>
|
|
|
|
<sect1>
|
|
<heading>
|
|
¿Qué 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ólica para <em/la versión
|
|
de desarrollo actual/ a la cual nos referimos simplemente como
|
|
<bf/-current/.
|
|
|
|
<p>Actualmente, <bf/-current/ es el desarrollo de la versión 4.0 y
|
|
la rama <bf/3.0-stable/ es <bf/RELENG_3/, separada de -current en Enero
|
|
de 1999.
|
|
|
|
<sect1>
|
|
<heading>
|
|
¿Có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ñade esto a tu fichero de configuració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ón ejecuta <tt/cvsup -g supfile/ para tener todos
|
|
los bits correctos en tu ordenador.
|
|
|
|
<p>Finalmente, necesitas una buena cantidad de espacio vacío para
|
|
crear en el la release. Digamos que está 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á creada en
|
|
<tt>/algun/disco/grande/</tt> y tendrás una instalació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ñadir <tt/RELEASETAG=SOMETAG/ a la línea
|
|
de comando anterior de creación de la release. Por ejemplo,
|
|
<tt/RELEASETAG=RELENG_2_2/ crearía un snapshot 2.2 GAMMA.
|
|
|
|
<sect1>
|
|
<heading>¿Cómo creo discos de instalación personalizados?</heading>
|
|
|
|
<p>El proceso completo de creacación de discos de
|
|
instalación y archivos fuentes y binarios esta automatizado por
|
|
varios targets en <tt>/usr/src/release/Makefile</tt>. La
|
|
información alli contenida debería ser suficiente para que
|
|
puedas empezar. Falta decir que este proceso necesita la ejecución
|
|
del comando "make world" y quizás te use mucho tiempo y espacio
|
|
en disco.
|
|
|
|
<sect1>
|
|
<heading>``make world'' destruye mis binarios instalados.</heading>
|
|
|
|
<p>Sí, 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á definida mientras se
|
|
ejecuta <tt/make world/ o <tt/make install/, los binarios creados
|
|
nuevamente seran depositados en un árbol de directorios
|
|
idéntico al instalado, y a partir de
|
|
<tt>${DESTDIR}</tt>. Algunas combinaciones aleatorias
|
|
de modificaciones de librerí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á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ón de configuración del kernel
|
|
<tt/TUNE_1542/ para que esto ocurra. En algunos sistemas puede
|
|
que puede hacer que los discos vayan más rápidos, pero en
|
|
otros puede que los datos queden corrompidos.
|
|
|
|
|
|
<sect1>
|
|
<heading>
|
|
¿Puedo seguir la rama current con acceso limitado a Internet?<label id="ctm">
|
|
</heading>
|
|
|
|
<p>Sí, puedes hacerlo <tt/sin/ bajarte todo el código
|
|
fuente usando la
|
|
utilidad <url url="../../handbook/synching.html#CTM" name="CTM.">
|
|
|
|
<sect1>
|
|
<heading>¿Cómo partir la distribución en ficheros de 240k?</heading>
|
|
|
|
<p>Los sistemas BSD más modernos tienen una opción
|
|
<tt/-b/ para partir que les permite partir los ficheros en
|
|
tamaños arbitrarios.
|
|
|
|
<p>Aqui hay un ejemplo de <tt>/usr/src/Makefile</tt>.
|
|
|
|
<verb>
|
|
bin-tarball:
|
|
(cd ${DISTDIR}; \
|
|
tar cf - . \
|
|
gzip --no-name -9 -c | \
|
|
split -b 240640 - \
|
|
${RELEASEDIR}/tarballs/bindist/bin_tgz.)
|
|
</verb>
|
|
|
|
<sect1>
|
|
<heading>¿He escrito una extensión del kernel, a quien la
|
|
envío?</heading>
|
|
|
|
<p>Por favor, mira en <url url="../../handbook/contrib.html"
|
|
name="como enviar código.">
|
|
|
|
<p>Y gracias por pensar en nosotros!
|
|
|
|
<sect1>
|
|
<heading>¿Có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í. Así, cuando comienza la rutina de prueba
|
|
de PnP, pregunta si hay alguna tarjeta PnP presente y todas las
|
|
tarjetas responden con su número de modelo a una lectura I/O
|
|
del mismo puerto. Así el có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ˆ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ólo para los
|
|
fabricantes parece un poco excesiva.
|
|
|
|
<p>La parte baja de 32 bits son un número de serie,
|
|
dirección ethernet, algo que haga a la tarjeta ú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í puedes tener múltiples tarjetas del mismo
|
|
tipo en la misma máquina y los 64 bits serán ú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úsqueda binaria
|
|
inicial.
|
|
|
|
<p>Una vez el sistema ha identificado todos los ID's de las tarjetas
|
|
presentes, reactivaráa cada tarjeta, una tras otra (a
|
|
través de los mismos puertos I/O), y encontrará los
|
|
recursos que cada tarjeta necesita, que opciones de interrupción
|
|
están disponibles, etc. Se realiza un escaneo sobre todas y cada
|
|
una de las tarjetas presentes para conocer esta información.
|
|
|
|
<p>Esta información se combina con la informació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ético, y los
|
|
periféricos no hacen PnP genuino. De todas maneras, examinando
|
|
la información de la BIOS más la información
|
|
ECU, la rutina de prueba puede causar que los dispositivos que no son
|
|
PnP puedan evitar a esos dispositivos que el código de prueba
|
|
no puede volver a posicionar.
|
|
|
|
<p>Así, los dispositivos PnP son visitados una vez más
|
|
y se les asigna su I/O, DMA, IRQ, direcciones del mapa de memoria. Los
|
|
dispositivos aparecerán en esas direcciones y permanecerán
|
|
en ellas hasta que se vuelva a reinicializar la máquina.
|
|
|
|
<p>Todo el proceso se ha simplificado mucho, pero espero que hayas podido
|
|
hacerte una idea del proceso.
|
|
|
|
<sect1>
|
|
<heading>¿Soporta FreeBSD arquitecturas diferentes a x86?</heading>
|
|
|
|
<p>Diferentes grupos de personas han expresado su interé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áquinas ALPHA,
|
|
entre ellas, AlphaStation, AXPpci, PC164, Miata y Multia. Este port
|
|
todavía no se considera una release completa y no lo será
|
|
hasta que exista una colección completa de herramientas de
|
|
instalación y una distribución completa en cdrom para
|
|
instalació, incluyendo un número razonable de ports y
|
|
packages funcionales. FreeBSD/AXP debe considerarse software de
|
|
calidad BETA en estos momentos. Para más información del
|
|
proyecto, subscríbete a la
|
|
<tt><FreeBSD-alpha@FreeBSD.org></tt><ref id="mailing"
|
|
name="lista de correo">.
|
|
|
|
También se ha expresado interés en un port de FreeBSD para
|
|
arquitectura SPARC. Subscríbete a
|
|
<tt><FreeBSD-sparc@FreeBSD.org></tt> <ref id="mailing"
|
|
name="la lista"> si estás interesado en participar en el proyecto.
|
|
Para discusiones generales en nuevas arquitecturas, participa en
|
|
<ref id="mailing" name="la lista">
|
|
<tt><FreeBSD-platforms@FreeBSD.org></tt>.
|
|
|
|
<sect1>
|
|
<heading>Necesito un numero de dispositivo para un driver propio</heading>
|
|
|
|
<p>Esto depende de si quieres hacer que el driver esté
|
|
públicamente disponible. Si la respuesta es afirmativa, por favor,
|
|
envianos una copia del código fuente del driver y las
|
|
modificaciones apropiadas del fichero <tt>files.i386</tt>, un ejemplo de
|
|
configuración y el có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><FreeBSD-hackers@FreeBSD.org></tt>.
|
|
|
|
<sect1>
|
|
<heading>Alternativas a la política de directorios</heading>
|
|
|
|
<p>En respuesta a esta pregunta de políticas alternativas
|
|
para los directorios, el esquema que está actualmente en uso
|
|
no ha cambiado desde que lo escribí en 1983. Escribí esa
|
|
política para el sistema de ficheros rápido original, y
|
|
nunca se ha revisado. Trabaja bié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úsqueda en
|
|
profundidad (también conocido como ftw). Estos directorios
|
|
terminan esparcidos a través de los grupos de cilindros. Si
|
|
conociesemos el número total de directorios a crear, la
|
|
solución sería crear (total / fs_ncg) por grupo de
|
|
cilindros antes de moverlos. Obviamente, tendriamos que crear
|
|
algún tipo de heurística para adivinar este número.
|
|
Usando un número pequeño fijo (como puede ser
|
|
10) haría de orden de magnitud. Para diferencial restores de
|
|
operaciones normales (cuando el algoritmo actual es probablemente
|
|
más sensible), podrís usar el clustering hasta 10 si
|
|
fueran todos hechos dentro de una ventana de diez segundos. De cualquier
|
|
manera, mi conclusión es que este es un área para la
|
|
experimentación.</p>
|
|
|
|
<p>Kirk McKusick, Septiembre 1998</p>
|
|
|
|
<sect1>
|
|
<heading>Obtener todo lo posible de un "kernel panic"</heading>
|
|
|
|
<p>
|
|
<em>[Esta secció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ïdan
|
|
Smørgrav">, quién a fijado algunos errores y
|
|
añ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>[<ben@rosengart.com> envió 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ón. En otras palabras, el valor varía
|
|
dependiendo de la imáden de kernel exacta que se use. Si
|
|
estás usando el kernel GENERIC de uno de los snapshots, entonces
|
|
es posible que alguien pueda seguir la función
|
|
problemática, pero si estás usando un kernel
|
|
personalizado, entonces solo <em>tú</em> puedes decirnos donde
|
|
ha ocurrido el fallo.
|
|
|
|
<p>Tendrías que hacer lo siguiente:
|
|
|
|
<itemize>
|
|
<item>Anotar el valor del puntero de la instrucció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ón.
|
|
El problema es que no obtendrás una búsqueda exacta ya
|
|
que los símbolos en la tabla de símbolos del kernel
|
|
son para los puntos de entrada de las funciones y la dirección
|
|
del puntero de la instrucción estará en algún
|
|
lugar dentro de una función, no al principio. Si no obtienes
|
|
un resultado exacto, omite el último dígito del valor
|
|
del puntero de la instrucción e intentalo otra vez, por
|
|
ejemplo:
|
|
<verb>
|
|
% nm /kernel.that.caused.the.panic | grep f0xxxxx
|
|
</verb>
|
|
Si esto no da ningún resultado, elimina otro dígito.
|
|
Repite la operación hasta que obtengas algún tipo de
|
|
salida. El resultado será una lista de posibles funciones
|
|
que causan el panic. Este no es un sistema muy exacto de
|
|
búsqueda de errores, pero es mejor que nada.
|
|
</itemize>
|
|
|
|
<p>Veo gente que constantemente envía mensajes de panics como
|
|
este, pero raramente veo que alguien se tome el tiempo de buscar
|
|
la coincidencia entre el puntero de instrucción y una
|
|
función en la tabla de sí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én los "dumps" de un crash del kernel; alguién
|
|
debería mirar esto antes de que la 3.0 salga del estado beta).
|
|
|
|
<p>En cualquier caso, el método que normalmente uso es este:
|
|
|
|
<itemize>
|
|
<item>Crear un fichero de configuración de kernel, opcionalmente
|
|
añadiendo 'options DDB' si piensas que necesitas el debugger
|
|
del kernel por algún motivo. (Uso esto principalmente para
|
|
configurar puntos de salida si sospecho que existe alguna
|
|
condición que crea un loop infinito).
|
|
<item>Usar <tt/config -g KERNELCONFIG/ para crear el directorio
|
|
de configuració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ún
|
|
motivo tu kernel es aú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ño. No tienes que
|
|
arrancar esta imán masiva, solo lo necesitas para poder usar
|
|
después <tt/gdb(1)/ (<tt/gdb(1)/ quiere la tabla de
|
|
símbolos). Al contrario, quieres mantener una copia de la
|
|
imágen completa y crear una segunda imágen con los
|
|
símbolos de debug desactivados usando <tt/strip -d/. Es esta
|
|
segunda imá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ón de swap. Esto hará que el script <tt/rc(8)/ use
|
|
el comando <tt/dumpon(8)/ para activar los "crash dumps". También
|
|
puedes ejecutar manualmente <tt/dumpon(8)/. Después de un panic,
|
|
el "crash dump" puede ser recuperado usando <tt/savecore(8)/; si
|
|
<tt/dumpdev/ está en <tt>/etc/rc.conf</tt>, el script
|
|
<tt/rc(8)/ ejecutará <tt/savecore(8)/ automaticamente y
|
|
pondrá el "crash dump" en <tt>/var/crash</tt>.
|
|
|
|
<p>NOTA: los "crash dumps" de FreeBSD suelen tener el mismo
|
|
tamaño que la cantidad total de memoria física del
|
|
sistema. Esto significa que si tienes 64MB de RAM, obtendrá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ón en
|
|
otro directorio donde tengas más espacio libre. Es posible
|
|
limitar el tamañ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íneas de información:
|
|
es una buena idea usar el comando <tt/script(1)/ para capturarlas
|
|
todas. Usando la imágen del kernel con todos los símbolos
|
|
de debug deberí mostrar la línea exacta de có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é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ías en la
|
|
máquina local.
|
|
|
|
<p><em>[Bill añade: "Olvidé 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á"]</em>
|
|
|
|
<sect1>
|
|
<heading>dlsym() no funciona con ejecutables ELF!</heading>
|
|
|
|
<p>Las herramientas ELF no hacen por defecto que los símbolos
|
|
definidos en un ejecutable sean visibles por el linker dinámico.
|
|
Consecuentemente, <tt/dlsym()/ buscará en datos obtenidos desde
|
|
llamadas a <tt>dlopen(NULL, flags)</tt>, lo que provoca que no se
|
|
encuentren esos símbolos.
|
|
|
|
<p>Si quieres buscar, usando <tt/dlsym()/ símbolos presentes
|
|
en el ejecutable principal de un proceso, necesitas linkar el
|
|
ejecutable usando la opció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áfico), es posible que notes que 256MB no es
|
|
suficiente.
|
|
|
|
<p>Así 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 él
|
|
mismo. Segundo, ya que el kernel se carga al inicio del espacio de
|
|
direcciones, necesitas disminuir la direcció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és resta uno
|
|
por UP y dos por SMP.
|
|
|
|
<p>Para solucionar el segundo aspecto, necesitas calcular la
|
|
dirección correcta de carga: simplemente resta el tamañ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ón pon el contador al inicio de la
|
|
secció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í; haciendo un
|
|
<tt/make world/ deberín solucionarse esos problemas (o una
|
|
recompilación manual de <tt/libkvm/, <tt/ps/ y <tt/top/
|
|
después de copiar el <tt/pmap.h/ parcheado a
|
|
<tt>/usr/include/vm/</tt>.
|
|
|
|
<p>NOTA: el tamaño del espacio de direcciones debe ser un
|
|
múltiplo de cuatro megabytes.
|
|
|
|
<p><em>[<url url="mailto:dg@FreeBSD.org" name="David Greenman">
|
|
añade: </em>Pienso que el espacio de direcciones del kernel
|
|
necesita ser una potencia de 2, pero no estoy totalmente seguro.]
|
|
|
|
</sect>
|