14.1. | ?Qué son SNAPs y RELEASEs? |
Hay actualmente tres ramas activas/semi-activas en el desarrollo de FreeBSD y en su CVS Repository:
HEAD no es una rama actual, como las otras dos, es
simplemente una constante simbólica para la versión
de desarrollo actual a la cual nos referimos simplemente como
Actualmente, | |
14.2. | ?Cómo puedo hacerme mi propia release personalizada? |
Para hacer una release necesitas hacer tres cosas: primero, necesitas usar un kernel con el driver vn configurado. Añade esto a tu archivo de configuración del kernel y crea un nuevo kernel:
Segundo, debes tener las herramientas del CVS a mano. Para hacer esto, puedes usar CVSUP pero en tu supfile pon el nombre de la release a cvs y borra cualquier tag campo de fecha:
*default prefix=/home/ncvs
A continuación ejecuta Finalmente, necesitas una buena cantidad de espacio vacío para
crear en el la release. Digamos que está en
Una release completa será creada en
| |
14.3. | ?Cómo creo discos de instalación personalizados? |
El proceso completo de creacación de discos de
instalación y archivos fuentes y binarios esta automatizado por
varios targets en | |
14.4. | ``make world'' destruye mis binarios instalados. |
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). Si la variable de entorno DESTDIR está definida mientras se ejecuta make world o make install, los binarios creados nuevamente seran depositados en un árbol de directorios idéntico al instalado, y a partir de ${DESTDIR}. Algunas combinaciones aleatorias de modificaciones de librerías compartidas y programas pueden causar que falle el make world. | |
14.5. | Cuando mi sistema arranca, dice (bus speed defaulted). |
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 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. | |
14.6. | ?Puedo seguir la rama current con acceso limitado a Internet? |
Sí, puedes hacerlo sin bajarte todo el código fuente usando la utilidad CTM. | |
14.7. | ?Cómo partir la distribución en archivos de 240k? |
Los sistemas BSD más modernos tienen una opción
Aqui hay un ejemplo de
bin-tarball:
| |
14.8. | ?He escrito una extensión del kernel, a quien la envío? |
Por favor, mira en como enviar código. Y gracias por pensar en nosotros! | |
14.9. | ?Cómo se detectan e inicializan las tarjetas ISA y PnP? |
Brevemente, hay unos cuantos puertos de entrada/salida a los que todas las tarjetas PnP responden cuando el computador 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). 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. 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. Los grupos de 32 bits nunca pueden ser todos cero. Esto permite mostrar todos los bits no-cero durante la búsqueda binaria inicial. 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. Esta información se combina con la información de los archivos 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 del 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. 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. Todo el proceso se ha simplificado mucho, pero espero que hayas podido hacerte una idea del proceso. | |
14.10. | ?Soporta FreeBSD arquitecturas diferentes a x86? |
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
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
También se ha expresado interés en un port de FreeBSD para
arquitectura SPARC. Subscríbete a
| |
14.11. | Necesito un numero de dispositivo para un driver propio |
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 archivo files.i386,
un ejemplo de configuración y el código apropiado de
MAKEDEV para
crear cualquier archivo especial que use tu dispositivo. Puedes enviar
todo lo necesario a | |
14.12. | Alternativas a la política de directorios |
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 archivos 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 archivos 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. Kirk McKusick, Septiembre 1998 | |
14.13. | Obtener todo lo posible de un "kernel panic" |
[Esta sección fue extraida de un mensaje escrito por Bill Paul en la lista FreeBSD-current por Dag-Erling Coïdan Smørgrav, quién a fijado algunos errores y añadido algunos comentarios entre corchetes]
From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
[<ben@rosengart.com> envió el siguiente panic] > Fatal trap 12: page fault while in kernel mode
[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 tú puedes decirnos donde ha ocurrido el fallo. Tendrías que hacer lo siguiente:
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. La mejor manera de hacer el seguimiento de la causa de un panic es
capturar un "crash dump", usando En cualquier caso, el método que normalmente uso es este:
[Nota: ahora que los kernels de FreeBSD 3.x son ELF por defecto
debes usar Ten en cuenta que TU NO QUIERES ARRANCAR CON UN
KERNEL QUE TIENE TODOS LOS SIMBOLOS DE DEBUG EN EL. Un kernel compilado
con Para asegurarte de capturar un "crash dump", necesitas editar el
archivo 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 Una vez hayas recuperado el "crash dump", puedes obtener una traza
del stack con
Es posible que aparezcan muchas líneas de información:
es una buena idea usar el comando Ahora, si eres realmente curioso y tienes un segundo computador,
puedes configurar [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á"] | |
14.14. | dlsym() no funciona con ejecutables ELF! |
Las herramientas ELF no hacen por defecto que los símbolos
definidos en un ejecutable sean visibles por el linker dinámico.
Consecuentemente, Si quieres buscar, usando | |
14.15. | Incrementando o reduciendo el espacio de direcciones del kernel |
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. 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. El primer aspecto lo solucionamos incrementando el valor de
NKPDE en
Para encontrar el valor correcto de NKPDE, divide el espacio de direcciones deseado (en megabytes) por cuatro, después resta uno por UP y dos por SMP. 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
LOAD_ADDRESS en
Reconfigura y compila el kernel. Probablemente tengas problemas con
NOTA: el tamaño del espacio de direcciones debe ser un múltiplo de cuatro megabytes. [David Greenman añade: Pienso que el espacio de direcciones del kernel necesita ser una potencia de 2, pero no estoy totalmente seguro.] |
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.