¿Alguien puede explicar qué hace exactamente el "oldconfig" de destino en el archivo makefile del kernel de Linux? Veo que se hace referencia en alguna documentación de compilación pero nunca expliqué qué hace exactamente.
¿Alguien puede explicar qué hace exactamente el "oldconfig" de destino en el archivo makefile del kernel de Linux? Veo que se hace referencia en alguna documentación de compilación pero nunca expliqué qué hace exactamente.
Respuestas:
Lee el .configarchivo existente y solicita al usuario opciones en la fuente actual del kernel que no se encuentran en el archivo. Esto es útil cuando se toma una configuración existente y se la mueve a un nuevo kernel.
Antes de ejecutar make oldconfig, debe copiar un archivo de configuración del kernel de un kernel anterior al directorio raíz del nuevo kernel.
Puede encontrar una copia del antiguo archivo de configuración del kernel en un sistema en ejecución en /boot/config-3.11.0. Alternativamente, el código fuente del kernel tiene configuraciones enlinux-3.11.0/arch/x86/configs/{i386_defconfig / x86_64_defconfig}
Si la fuente de su kernel se encuentra en /usr/src/linux:
cd /usr/src/linux
cp /boot/config-3.9.6-gentoo .config
make oldconfig
Resumen
Como lo mencionó Ignacio , actualiza su .configpor usted después de actualizar la fuente del kernel, por ejemplo, con git pull.
Intenta mantener sus opciones existentes.
Tener un guión para eso es útil porque:
Es posible que se hayan agregado nuevas opciones o que se hayan eliminado las antiguas.
El formato de configuración Kconfig del kernel tiene opciones que:
selectdependsEsas relaciones de opciones hacen que la resolución de configuración manual sea aún más difícil.
Modifiquemos .config manualmente para comprender cómo resuelve las configuraciones
Primero genere una configuración predeterminada con:
make defconfig
Ahora edite el .configarchivo generado manualmente para emular una actualización del kernel y ejecute:
make oldconfig
para ver que pasa. Algunas conclusiones:
Líneas de tipo:
# CONFIG_XXX is not set
no son meros comentarios, sino que en realidad indican que el parámetro no está configurado.
Por ejemplo, si eliminamos la línea:
# CONFIG_DEBUG_INFO is not set
y corre make oldconfig, nos preguntará:
Compile the kernel with debug info (DEBUG_INFO) [N/y/?] (NEW)
Cuando termine, el .configarchivo se actualizará.
Si cambia cualquier carácter de la línea, por ejemplo # CONFIG_DEBUG_INFO, a , no cuenta.
Líneas de tipo:
# CONFIG_XXX is not set
siempre se utilizan para la negación de una propiedad, aunque:
CONFIG_XXX=n
también se entiende como la negación.
Por ejemplo, si elimina # CONFIG_DEBUG_INFO is not sety responde:
Compile the kernel with debug info (DEBUG_INFO) [N/y/?] (NEW)
con N, entonces el archivo de salida contiene:
# CONFIG_DEBUG_INFO is not set
y no:
CONFIG_DEBUG_INFO=n
Además, si modificamos manualmente la línea para:
CONFIG_DEBUG_INFO=n
y ejecutar make oldconfig, luego la línea se modifica a:
# CONFIG_DEBUG_INFO is not set
sin oldconfigpreguntarnos.
Las configuraciones cuyas dependencias no se cumplen no aparecen en el .config. Todos los demás lo hacen.
Por ejemplo, configure:
CONFIG_DEBUG_INFO=y
y corre make oldconfig. Será ahora nos piden: DEBUG_INFO_REDUCED, DEBUG_INFO_SPLIT, etc. configuraciones.
Esas propiedades no aparecieron defconfigantes.
Si miramos debajo de lib/Kconfig.debugdonde se definen, vemos que dependen de DEBUG_INFO:
config DEBUG_INFO_REDUCED
bool "Reduce debugging information"
depends on DEBUG_INFO
Entonces, cuando DEBUG_INFOestaba fuera, no aparecieron en absoluto.
Las configuraciones que están selectedactivadas se establecen automáticamente sin preguntar al usuario.
Por ejemplo, si CONFIG_X86=yy eliminamos la línea:
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
y corre make oldconfig, la línea se recrea sin preguntarnos, a diferencia de DEBUG_INFO.
Esto sucede porque arch/x86/Kconfig contiene:
config X86
def_bool y
[...]
select ARCH_MIGHT_HAVE_PC_PARPORT
y seleccionar fuerza a que esa opción sea verdadera. Consulte también: /unix/117521/select-vs-depends-in-kernel-kconfig
Se solicitan configuraciones cuyas restricciones no se cumplan.
Por ejemplo, defconfighabía establecido:
CONFIG_64BIT=y
CONFIG_RCU_FANOUT=64
Si editamos:
CONFIG_64BIT=n
y corre make oldconfig, nos preguntará:
Tree-based hierarchical RCU fanout value (RCU_FANOUT) [32] (NEW)
Esto se debe a que RCU_FANOUTse define en init/Kconfigcomo:
config RCU_FANOUT
int "Tree-based hierarchical RCU fanout value"
range 2 64 if 64BIT
range 2 32 if !64BIT
Por lo tanto, sin 64BIT, el valor máximo es 32, pero habíamos 64establecido en .config, lo que lo haría inconsistente.
Bonificaciones
make olddefconfigestablece cada opción en su valor predeterminado sin preguntar de forma interactiva. Se ejecuta automáticamente makepara garantizar que .configsea coherente en caso de que lo haya modificado manualmente como lo hicimos nosotros. Consulte también: /server/116299/automatically-answer-defaults-when-doing-make-oldconfig-on-a-kernel-tree
make alldefconfiges como make olddefconfig, pero también acepta un fragmento de configuración para fusionar. Este destino es utilizado por el merge_config.shscript: https://stackoverflow.com/a/39440863/895245
Y si desea automatizar la .configmodificación, eso no es demasiado simple: ¿Cómo se activan las características de forma no interactiva en un archivo .config del kernel de Linux?
Actualiza una configuración antigua con opciones nuevas / modificadas / eliminadas.
De esta pagina :
Make oldconfig toma el .config y lo ejecuta a través de las reglas de los archivos Kconfig y produce un .config que es consistente con las reglas de Kconfig. Si faltan valores CONFIG, make oldconfig los pedirá.
Si el .config ya es consistente con las reglas que se encuentran en Kconfig, entonces make oldconfig es esencialmente una operación no operativa.
Si tuviera que ejecutar make oldconfig y luego ejecutar make oldconfig por segunda vez, la segunda vez no hará que se realicen cambios adicionales.
Es una tortura. En lugar de incluir un archivo conf genérico, le hacen presionar retorno 9000 veces para generar uno.
yes "" | make oldconfig