Hay actualmente tres ramas activas/semi-activas en el desarrollo de
FreeBSD y en su
Para hacer una release necesitas hacer tres cosas: primero,
necesitas usar un kernel con el driver Segundo, debes tener las herramientas del CVS a mano. Para hacer
esto, puedes usar
A continuación ejecuta Finalmente, necesitas una buena cantidad de espacio vacío para
crear en el la release. Digamos que está en
/algun/disco/grande y en el ejemplo anterior has dejado los
ficheros del CVS en /home/ncvs:
Una release completa será creada en
/algun/disco/grande/ y tendrás una instalación
completa de tipo FTP en /algun/disco/grande/R/ftp cuando acabes.
Si quieres crear tu SNAP usando otra rama de desarrollo diferente de
-current, puedes añadir
El proceso completo de creacación de discos de
instalación y archivos fuentes y binarios esta automatizado por
varios targets en /usr/src/release/Makefile. 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.
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}. Algunas combinaciones aleatorias
de modificaciones de librerías compartidas y programas pueden
causar que falle el
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
Sí, puedes hacerlo
Los sistemas BSD más modernos tienen una opción
Aqui hay un ejemplo de /usr/src/Makefile.
Por favor, mira en Y gracias por pensar en nosotros!
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).
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
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.
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.
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 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 files.i386, un ejemplo de
configuración y el código apropiado de 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. Kirk McKusick, Septiembre 1998
[Esta sección fue extraida de un mensaje escrito por
[<ben@rosengart.com> envió el siguiente panic]
[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 Para asegurarte de capturar un "crash dump", necesitas editar el
fichero /etc/rc.conf y apuntar /etc/rc.conf, el script
/var/crash.
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 /var/crash. Alternativamente puedes
ejecutar 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 ordenador,
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á"]
Las herramientas ELF no hacen por defecto que los símbolos
definidos en un ejecutable sean visibles por el linker dinámico.
Consecuentemente, dlopen(NULL, flags), lo que provoca que no se
encuentren esos símbolos.
Si quieres buscar, usando -export-dynamic en el
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
src/sys/i386/include/pmap.h. Esta es una entrada
de ejemplo para 1GB de espacio de direcciones:
Para encontrar el valor correcto de 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
src/sys/i386/conf/Makefile.i386 a ese
valor; a continuación pon el contador al inicio de la
sección listado en src/sys/i386/conf/kernel.script
al mismo valor, como sigue:
Reconfigura y compila el kernel. Probablemente tengas problemas con
/usr/include/vm/.
NOTA: el tamaño del espacio de direcciones debe ser un
múltiplo de cuatro megabytes.
[