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.
