Re: [Kernel] Decir 'y' o decir 'm'
Javi Castelo wrote:
Hola,
... he ahí mi dilema.
Hasta ahora sólo he compilado el kernel (versión 2.4.16) una vez y
bajo el entorno X. Sin embargo sigo arrancando con el 2.2.18pre21.
Tengo bastantes dudas que al leer libros y documentación diversa se
duplican, a saber:
1.- Cuando navegaba por las distintas opciones que me interesaban (por
ejemplo una SB AWE-32 ) le daba click al botón de ayuda antes de
marcar y me decía algo así como: "contesta 'y' si tienes esa tarjeta
de sonido". El caso es que si contestas sí ('y') en vez de 'm' el
driver se compila en el kernel y evidentemente no puedes instalar y
configurar la tarjeta como módulo. La tarjeta de sonido no funcionó ni
añadiendo la correspondiente línea en el LILO (append= ...lo que
proceda) tal y como decía en la propia ayuda del kernel mencionada.
Pregunto: Si una de las ventajas del kernel es que puedes configurar
un sistema altamente modular, con módulos que se cargan segun lo
demanda el sistema y en definitiva el usuario...
¿ Porqué en la ayuda de la configuración del kernel recomiendan que
contestes 'y' en vez de 'm' a todo lo que quieras darle servicio o
utilizar?
Hay alguna ventaja al compilarlo dentro del kernel, y es que irá un
pelín más rápido (aunque no sea nada apreciable), consume un poco menos
memoria y los novatos no se tienen que preocupar de cargar el módulo.
Otro tanto podríamos decir del resto de opciones. Entonces ...
¿Qué me recomendais que compile en el kernel y qué como módulo?
Yo te recomendaría que compilases como módulo todo aquello que:
- uses poco o raras veces y ocupe una cantidad apreciable de memoria.
- pueda dar problemas de compatibilidad con otros módulos o programas en
ciertos momentos.
- no estés seguro de si deberías usar.
Al hilo de esto he mirado lo que contiene el fichero
/boot/Config-2.2.18pre21 que casualmente resulta ser cómo se configuró
el kernel durante la instalación y la práctica totalidad de las
opciones están marcadas com 'm' y muy pocas con 'y'. ¡¡ Vale !!
durante la instalación Debian "se cura en salud" pues no sabe lo que
el usuario va a instalar en el sistema ¿O no? ... ¿O se hace así
porque es una buena metodología para configurar el kernel?
Evidentemente no contestaremos ni 'y' ni 'm' a lo que no
tengamos/queramos o vayamos a tener. Pero ... ¿Y al resto?
Se hace así porque se compila soporte para muchos dispositivos y
funcionalidades. Es un kernel para todos en general y para nadie en
concreto. De manera que después cada uno puede seleccionar lo que le
hace falta y no tener que tragar con un kernel de 2Mb que tiene más
cosas de las que hacen falta y que podría dar problemas al tener
compilado funcionalidades que puede ser incompatibles entre sí o no
funcionar demasiado bien en algunos casos.
Si te compilas un kernel a medida, está claro que no lo vas a hacer así.
2.- La documentación que he leido a la hora de compilar el kernel dice
que es muy importante que junto a la imagen del nucleo compilado se
acompañe el fichero generado System.map-XX.XX.XX. Además se
recomienda añadir a lilo.conf una entrada para el nuevo kernel (por
si algo va mal).
Cierto.
Sin embargo no se dice que antes de la correspondiente sección del
núcleo con el que arrancar ya hay una línea en lilo.conf que dice algo
así como map=/boot/map. Es decir, por mucho que creemos en lilo.conf
entrada al nuevo kernel y acompañemos junto a la imagen el nuevo
System.map, el nuevo kernel arrancará con el antiguo map :-?
Esto no tiene mucho sentido salvo que suprimieramos la entrada
map=/boot/map anterior a las de los kernel y dentro de cada sección
image=/boot/kernel-XX.XX.XX pongamos map=/boot/System.map-XX.XX.XX
para cada kernel.
Que yo sepa no es así. No te lo sé razonar ahora mismo, pero no he
tenido nunca problemas en ese sentido. En el image se suelen usar en laces:
/vmlinuz -> boot/kernel-xx.xx.xx
/vmlinuz.old -> boot/kernel-yy.yy.yy
Supongo que sabe adivinar qué map tiene que coger. No te sé decir seguro.
Una cosa que no has mencionado es que debes mantener el
/lib/modules/xx.xx.xx con los módulos del kernel antiguo. No has de
hacer nada, pero recuerda que no los debes borrar. Y que la versión de
seguridad del kernel no sea la misma que la nueva que vas a probar,
porque habrás machacado los modulos antiguos con los nuevos.
¿Alguien ha probado hacer esto? o en su defecto
¿Cómo hacer que cada kernel inicie con su System.map?
Un saludo.
Reply to: