Pues muchas gracias, los ficheros de configuración son los Config.in
He creado un Config.in en una carpeta colgando del /source con algo así:
mainmenu_option next_comment
comment '¡Driver Hack!'
tristate 'Modulo Tps ' CONFIG_TPS
tristate 'Modulo SLCDC' CONFIG_SLCDC
endmenu
Y por último hay que añadir en algún lado una referencia a este Config.in para que el menu te lo coja, es hecho:
vi arch/i386/config.in
Y he añadido al final: source driver_hack/Config.in y voilá u nuevo menu en el menuconfig , ahora ya solo falta que dependiendo de la variable se compile correctamente el modulo... de momento toca leerse la doc sobre kconfig del kernel
Ferdy escribió:Si como tu dices son cosas que la máquina de destino no tiene, simplemente olvídate de ellas o haz el desarrollo al revés, manteniendo tu mismo una rama del kernel 2.4 y aplicando selectivamente los cambios que se hagan a la rama principial. Parece mejor idea...
Hombre, tu idea es mejor si tubiera ke ir modificando el kernel para ir adaptandola a las nuevas versiones que aparecieran del 2.4...
Pero yo básicamente, lo quiero dejar fetén para mi versión ( 2.4.20 ) , no creo que mantenga el kernel a lo largo de muchas más versiones de la 2.4 .
Más que nada, porque el curro que supone es bestial, así que lo que yo intentaré si tengo que seguir con el desarrollo, es intentar migrar a la rama 2.6 y ahí si ke podría hacer lo que dices....
Llegado a este punto lo que me interesa es que cuando el kernel este listo, eliminar las opciones superfluas para que luego no me estén machacando otros con si esto puede ponerse o no en el menuconfig, pero quizás, modificando el fichero del menu para que esas opciones no salgan sería suficiente xD ( y tp importaría ya si quedaran ficheros vacíos , supongo )
1 Salu2 && Txh
