Libertonia || Comments || Guía de compilación del núcleo Linux para torpes ;-)


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Guía de compilación del núcleo Linux para torpes ;-) | 20 comentarios (11 temáticos, 9 editoriales, 0 ocultos)

La respuesta es sencilla: (3.66 / 3) (#17)
por iarenaza a las Wed Jan 8th, 2003 at 10:42:44 PM CET
(Información Usuario) http://www.escomposlinux.org/

solo hay un par de casos en los cuales puedes evitar hacer el make dep, y un monton de ellos en los cuales no.

Explicar todos los detalles tecnicos que tu has dado arriba para mencionar que en esos casos y sólo en esos nos podemos ahorrar algo de tiempo (teniendo en cuenta el tiempo total de compilacion), es mas rapido, directo y menos lioso para quien no conoce o no quiere conocer los detalles, decir que se haga siempre el famoso make dep y listo.

Saludos. Iñaki.

[ Padre ]

No tan sencilla :-) (5.00 / 2) (#18)
por jorginius ("jorginius" en Google Mail) a las Thu Jan 9th, 2003 at 12:16:46 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Explicar todos los detalles tecnicos que tu has dado arriba para mencionar que en esos casos y sólo en esos nos podemos ahorrar algo de tiempo (teniendo en cuenta el tiempo total de compilacion)

Tal y como lo expones, parece que consideras que hablo de "casos marginales". Realmente "esos casos" en los que no hace falta un "make dep" son prácticamente todos los casos posibles... Salvo uno:

La primera vez que vayamos a compilar de unas fuentes "pristinas", hay que construir las dependencias. A partir de ahí se pueden reutilizar sin problemas todas las veces que recompilemos las fuentes, por mucho que cambiemos la configuración.

Sin obviar que distribuciones como RedHat incluyen en sus fuentes del kernel las dependencias ya creadas, con lo cual instalando el rpm de kernel-sources incluso nos podemos ahorrar el primer "make dep".

Por otro lado, el tiempo que ahorramos evitando reconstruir las dependencias es significativo... Según se puede ver reflejado en el grandioso Kernel-Aaargh! de runlevel0 :-). ¿Que no parece gran cosa comparado con lo que tarda en compilar el kernel?. Depende:

Imagina que en tu máquina tarda 20 minutos en construir las dependencias y 2-3 horas en compilar el kernel (¿ya te lo imaginas? :-)).

Ahora configuras y compilas y, al terminar, te das cuenta de que tendrías que haber añadido soporte para algo más en forma de módulo o lo que sea (a mí lo que siempre se me queda en el tintero es el "Socket Filtering", sin el cual el DHCP no va %-}). ¿Cuanto tardas en activar la opción, y recompilar el kernel?: escasamente 5 minutos. ¿Cuanto tardarías en hacerlo si tuvieras que reconstruir las dependencias?: cinco veces más (20 minutos el "make dep", 5 minutos el make del kernel).

Visto así, sí parece que ahorra tiempo ¿no?.

... Y de cualquier forma, emplear esos 5/30 minutos (según hw) para hacer algo productivo me parece más eficiente que dedicarlos a darle trote al disco y a la cpu haciendo tareas redundantes.

Es mas rapido, directo y menos lioso para quien no conoce o no quiere conocer los detalles, decir que se haga siempre el famoso make dep y listo.

También le estamos contando algo incorrecto al que "no conoce o no quiere conocer los detalles". ¿Eso vale cómo argumento en mi defensa?.

Es más, no sé si tú te incluyes en el grupo de personas que "no quiere conocer los detalles". Creo que no es el caso, pero aún así dijiste que:

[Las dependencias si hay que reconstruirlas] cada vez, ya que al elegir opciones nuevas, quitar viejas, etc. el codigo a compilar y las dependencias entre los diferentes modulos cambian.

Runlevel0 comentó algo parecido:

['dep'] en kernels monolíticos sólo se necesitaría correr una vez, pero claro, hoy en día ¿Quién quiere kernels monolíticos?.

Ambas afirmaciones parecen erroneas, luego lo de "hacer el make dep siempre" no se trata de "una muletilla" que ayuda al novato. Es un error extendido incluso entre la gente que sí se preocupa de los detalles, como nosotros tres, supongo :-).

Me concederas al menos que hay una errata muy extendida en la documentación al respecto. Parece que el contenido de kbuild/* ha quedado desfasado... Hasta que alguien demuestre lo contrario, por supuesto.

[ Padre ]

Creo que no me explico bien (3.00 / 2) (#19)
por iarenaza a las Fri Jan 10th, 2003 at 12:01:21 AM CET
(Información Usuario) http://www.escomposlinux.org/

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 (ojo, muy interesantes por otra parte para quien si quiera ahorrarse esos minutos[1] o segundos extra[2], además de ser formativo) me parece simplemente estar más allá de las necesidades del tutorial, de las expectativas de sus lectores y, probablemente, de su capacidad para asimilar y comprender esos detalles tan técnicos.

De ahí mi respuesta.

Saludos. Iñaki.

[1] Si, he compilado kernels en maquinas en las cuales las dependencias se llevaban su buenos 30-35 minutos y la compilacion del kernele sus dos buenas horas adicionales, asi que se a lo que te refieres :)

[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:

tu maquina es lo suficientemente rapida como para que no te importe poner cuidado al hacer make config y tener que recompilar una o mas veces. En este caso, como es tan rapida, el ahorro de tiempo de no hacer el make dep es mínimo.
tu maquina es tan lenta compilando que el evitarte el hacer make dep si solo has cambiado algo en el kernel porque se te ha olvidado la primera vez, merece la pena. En este caso, tengo la fundada sospecha que no llegas a hacer estas recompilaciones casi nunca, por la sencilla razon de que eres consciente de que cada vez que compilas el kernel (desde cero o por haber modificado solo una cosilla), le cuesta horrores (es mas una sensacion psicológica que una situación objetiva seguramente, pero al final es la que marca tus acciones). En ese caso pones buen cuidado de elegir todo lo que necesitas desde el principio, para tener que hacerlo una sola vez, con lo cual no te ahorras el make dep de turno :)

Por tanto podemos concluir que no es una errata en la documentación, simplemente es una simplificacion del caso general para describir el proceso mas habitual.

[ Padre ]

... O a lo mejor no me entiendes (3.00 / 2) (#20)
por jorginius ("jorginius" en Google Mail) a las Fri Jan 10th, 2003 at 01:56:55 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

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 ]

Guía de compilación del núcleo Linux para torpes ;-) | 20 comentarios (11 temáticos, 9 editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda