La noticia hace referencia a un mini-tutorial sobre como compilar el kernel paso a paso. No es una obra completa sobre los entresijos de la compilación del kernel, kbuild1 y saber que es eso de MODVERSIONs.
Con esa premisa, y teniendo en cuenta el publico al que va dirijido, entrar en las consideraciones que tu haces [...] me parece simplemente estar más allá de las necesidades del tutorial
Entiendo que una descripción pomenorizada de lo que va haciendo cada target del Makefile del kernel no tiene sentido en un tutorial para novatos.
Yo no pondría en mini-cómo algo como eso. Pero sí quizás un:
"... Este paso sólo lo tienes que hacer una vez, al descomprimir las fuentes del kernel y después del primer 'make menuconfig'. A partir de ahora, si quieres hacer pruebas, añadir y quitar opciones o compilar otro kernel para otro ordenador menos potente con otro hardware, el 'make dep' te lo puedes saltar"
"... Recuerda que cuando haces un 'make mrproper' vuelves a tener las fuentes del kernel tal y como te las bajaste, así que antes de volver a compilar tendrás que hacer de nuevo un 'make menuconfig' y un 'make dep'"
Entonces, si lo que creo que podría encajar en el mini-cómo es eso, ¿por qué posteo el otro rollo técnico-infumable?: es que me sirve para argumentar lo que dije en este comentario editorial, que es el padre del hilo que trato de seguir en estos comentarios temáticos, de que las recetas mecánicas no me gustan mucho y las de compilar el kernel menos porque tradicionalmente no muestran "la forma correcta de hacer las cosas".
Además, después de decir yo "no hace falta hacer el 'make dep'" y tú responder "sí hace falta", creí que vendría bien mirarlo en detalle para salir de dudas.
Partimos de que la muletilla "make menuconfig && make dep && make clean && make bzImage && make modules && ..." se usa entera toda ella inconscientemente, sin cuestionarse si hay formas mejores de hacerlo o de si hace falta todo aquello... Porque a ver, que levante la mano el que no la use sin pensar cada vez que compile el kernel :-). Incluso runlevel0 lo llama "mantra" aquí, y por el nivel de difusión/aceptación de la fórmula mágica, parece un nombre de lo más apropiado.
Supongo que tú me dirás que si funciona y es lo que todo el mundo (je), para qué preocuparse... Hombre, pues no niego que funciona... Pero es que creo que no es sólo eso lo que se busca. A ver si explico lo que quiero decir:
¿Nunca has escuchado/leído algo como "las X del Linux me estaban fallando, así que formateé y reinstalé", y a lo mejor quien lo dijo estaba tan contento porque su (drástica) solución le funcionó?. No sé a ti pero a mí en esas ocasiones me resulta difícil permanecer callado sin decir "pues había una forma mejor de hacerlo, para la próxima vez prueba...".
Con esto del "make dep" me pasa algo parecido. Me parece tan "a cañonazos" y superfluo que tengo que decirlo ;-)
Ahora respondo la parte cotilla de tu comentario (atención lector: sino eres iarenaza te aconsejo que te lo saltes :-)).
[2] Esta ya es para polemizar :) Si te fijas, el ahorro que tu propones sólo se produce en caso de tener que recompilar el kernel con alguna modificacion. En ese caso podemos tener dos posibles escenarios:
Lo del "Socket Filtering" nos paso dos veces (el hombre es el único animal que tropieza dos veces en la misma piedra) pero te faltan por enumerar al menos dos escenarios, que me resultan mucho más conocidos :-).
En la universidad tenemos un montón de máquinas lentas SPARC (no sé si tienes experiencia con cacharros como esos, pero para que te hagas una idea, la compilación de un kernel en un SS 5 nos lleva unas seis horas y en una Classic directamente habría que dejarlas toda la noche), agrupadas por perfiles, según la tarea que desempeñan. Para cada perfil tenemos un kernel personalizado: en total creo que son cinco kernels distintos.
Como todas las máquinas son variantes de v8, podemos compilar el kernel para cada perfil simplemente compilando una vez, cambiando las opciones, haciendo de nuevo el 'make' y ahorrando un montón de tiempo sin compilar muchos archivos fuente y sin recalcular dependencias.
En realidad, se podría haber incluso ahorrado más tiempo ya que también tenemos unas cuantas Ultra más potentes sobre las que compilar... Pero hasta hace dos meses no sabíamos que se podían compilar kernels para v8 en las Ultra sin necesidad de un compilador cruzado (En las SPARC no es como en PC, que todos los micros se engloban en la misma familia: aquí tienes una rama del kernel para v9, de 64 bits, disjunta de la de v8, de 32). De todas formas, las Ultra tampoco son muy potentes, así que el tiempo que se ahorra compilando kernels sucesivos sin reconstruir las dependencias (y sin hacer el 'make clean', claro) sigue siendo considerable. Por lo menos, ya lo sabemos para cuando haya que actualizar todos los kernels.
Por cierto, ¿por qué esa manía inicial de recompilar el kernel en las SPARCS?, pues porque el kernel que viene con Debian para las SPARC32 es exclusivamente un 2.2.x, sin soporte entre otras cosas para ext3 (Y no me contéis que arrancando con el cd nosequé te instala un 2.4.x por que nó. En SPARC32, Woody no da opción de un 2.4.x).
Eso por un lado, y después tenemos el otro escenario, compuesto por yo mismo intentando depurar un 2.4.18 en una SS5 porque el khttpd no va en ellas (y en las Ultra y en los PC sí ???), por el método de "leer código, poner printk(), recompilar, reiniciar y probar a ver" (por si alguien siente curiosidad, el problema era que los hilos que atendían las peticiones del kernel se quedaban zombies nada más empezar a atender a la conexión entrante y no sólo era depurar, también había que añadir una funcionalidad nueva bastante chorra).
Si cada vez que hubo que poner comprobaciones de errores y recompilar para probar aquel engendro, hubieramos tenido que reconstruir las dependencias en esa máquina, todavía seguiríamos allí :-P.
[ Padre ]
|
