Lógicamente, la infraestructura de Kconfig consta de dos partes:una implementa un nuevo lenguaje para definir los elementos de configuración (consulte los archivos de Kconfig en el código fuente del kernel) y la otra analiza el lenguaje de Kconfig y se ocupa de las acciones de configuración.
La mayoría de los objetivos de configuración tienen aproximadamente el mismo proceso interno (que se muestra a continuación):
Tenga en cuenta que todos los elementos de configuración tienen un valor predeterminado.
El primer paso lee el archivo Kconfig en la raíz de origen para construir una base de datos de configuración inicial; luego actualiza la base de datos inicial leyendo un archivo de configuración existente de acuerdo con esta prioridad:
.config
/lib/modules/$(shell,uname -r)/.config
/etc/kernel-config
/boot /config-$(shell,uname -r)
ARCH_DEFCONFIG
arch/$(ARCH)/defconfig
Si está realizando una configuración basada en GUI a través de menuconfig o configuración basada en línea de comandos a través de oldconfig , la base de datos se actualiza según su personalización. Finalmente, la base de datos de configuración se vuelca en el archivo .config.
Pero el archivo .config no es el forraje final para la construcción del kernel; esta es la razón por la que syncconfig el objetivo existe. configuración de sincronización solía ser un objetivo de configuración llamado silentoldconfig , pero no hace lo que dice el nombre anterior, por lo que se le cambió el nombre. Además, debido a que es para uso interno (no para usuarios), se eliminó de la lista.
Aquí hay una ilustración de lo que syncconfig hace:
configuración de sincronización toma .config como entrada y genera muchos otros archivos, que se dividen en tres categorías:
Después de la configuración, sabremos qué archivos y piezas de código no están compilados.
kconstruir
Construcción por componentes, llamada marca recursiva , es una forma común para GNU make para gestionar un gran proyecto. Kbuild es un buen ejemplo de make recursivo. Al dividir los archivos fuente en diferentes módulos/componentes, cada componente es administrado por su propio archivo MAKE. Cuando comienza a compilar, un archivo MAKE superior invoca el archivo MAKE de cada componente en el orden correcto, compila los componentes y los recopila en el ejecutivo final.
Kbuild se refiere a diferentes tipos de archivos MAKE:
- Archivo Make es el archivo MAKE superior ubicado en la raíz de origen.
- .config es el archivo de configuración del kernel.
- arch/$(ARCH)/Makefile es el archivo MAKE arch, que es el complemento del archivo MAKE superior.
- scripts/Makefile.* describe reglas comunes para todos los archivos MAKE de kbuild.
- Finalmente, hay alrededor de 500 kbuild makefiles .
El archivo make superior incluye el archivo make arch, lee el archivo .config, desciende a los subdirectorios, invoca make en el archivo MAKE de cada componente con la ayuda de rutinas definidas en scripts/Makefile.* , crea cada objeto intermedio y vincula todos los objetos intermedios en vmlinux. El documento del kernel Documentation/kbuild/makefiles.txt describe todos los aspectos de estos makefiles.
Como ejemplo, veamos cómo se produce vmlinux en x86-64:
Todos los .o los archivos que van a vmlinux primero van a su propio incorporado.a , que se indica mediante variables KBUILD_VMLINUX_INIT , KBUILD_VMLINUX_MAIN , KBUILD_VMLINUX_LIBS , luego se recopilan en el archivo vmlinux.
Eche un vistazo a cómo se implementa la creación recursiva en el kernel de Linux, con la ayuda del código simplificado del archivo MAKE:
# In top Makefile
vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps)
+$(call if_changed,link-vmlinux)
# Variable assignments
vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN) $(KBUILD_VMLINUX_LIBS)
export KBUILD_VMLINUX_INIT := $(head-y) $(init-y)
export KBUILD_VMLINUX_MAIN := $(core-y) $(libs-y2) $(drivers-y) $(net-y) $(virt-y)
export KBUILD_VMLINUX_LIBS := $(libs-y1)
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
init-y := init/
drivers-y := drivers/ sound/ firmware/
net-y := net/
libs-y := lib/
core-y := usr/
virt-y := virt/
# Transform to corresponding built-in.a
init-y := $(patsubst %/, %/built-in.a, $(init-y))
core-y := $(patsubst %/, %/built-in.a, $(core-y))
drivers-y := $(patsubst %/, %/built-in.a, $(drivers-y))
net-y := $(patsubst %/, %/built-in.a, $(net-y))
libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))
virt-y := $(patsubst %/, %/built-in.a, $(virt-y))
# Setup the dependency. vmlinux-deps are all intermediate objects, vmlinux-dirs
# are phony targets, so every time comes to this rule, the recipe of vmlinux-dirs
# will be executed. Refer "4.6 Phony Targets" of `info make`
$(sort $(vmlinux-deps)): $(vmlinux-dirs) ;
# Variable vmlinux-dirs is the directory part of each built-in.a
vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
$(core-y) $(core-m) $(drivers-y) $(drivers-m) \
$(net-y) $(net-m) $(libs-y) $(libs-m) $(virt-y)))
# The entry of recursive make
$(vmlinux-dirs):
$(Q)$(MAKE) $(build)=$@ need-builtin=1
La receta make recursiva se expande, por ejemplo:
make -f scripts/Makefile.build obj=init need-builtin=1
Esto significa hacer irá a scripts/Makefile.build para continuar el trabajo de construcción de cada incorporado.a . Con la ayuda de scripts/link-vmlinux.sh , el archivo vmlinux finalmente está bajo la raíz de la fuente.
Comprender vmlinux versus bzImage
Es posible que muchos desarrolladores del kernel de Linux no tengan clara la relación entre vmlinux y bzImage. Por ejemplo, aquí está su relación en x86-64:
La fuente raíz vmlinux se elimina, se comprime y se coloca en piggy.S , luego vinculado con otros objetos del mismo nivel en arch/x86/boot/compressed/vmlinux . Mientras tanto, se genera un archivo llamado setup.bin en arch/x86/boot. . Puede haber un tercer archivo opcional que tenga información de reubicación, según la configuración de CONFIG_X86_NEED_RELOCS .
Un programa host llamado build , proporcionada por el núcleo, crea estas dos (o tres) partes en el archivo bzImage final.
Seguimiento de dependencia
Kbuild rastrea tres tipos de dependencias:
- Todos los archivos de requisitos previos (ambos *.c y *.h )
- CONFIG_ opciones utilizadas en todos los archivos de requisitos previos
- Dependencias de la línea de comandos utilizadas para compilar el objetivo
El primero es fácil de entender, pero ¿qué pasa con el segundo y el tercero? Los desarrolladores del kernel a menudo ven fragmentos de código como este:
#ifdef CONFIG_SMP
__boot_cpu_id = cpu;
#endif
Cuando CONFIG_SMP cambios, este fragmento de código debe volver a compilarse. La línea de comando para compilar un archivo de origen también es importante, porque diferentes líneas de comando pueden generar diferentes archivos de objetos.
Cuando un .c El archivo usa un archivo de encabezado a través de un #include directiva, necesita escribir una regla como esta:
main.o: defs.h
recipe...
Al administrar un proyecto grande, necesita muchos de estos tipos de reglas; escribirlos todos sería tedioso y aburrido. Afortunadamente, la mayoría de los compiladores de C modernos pueden escribir estas reglas mirando el #include líneas en el archivo fuente. Para GNU Compiler Collection (GCC), solo es cuestión de agregar un parámetro de línea de comando:-MD depfile
# In scripts/Makefile.lib
c_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
-include $(srctree)/include/linux/compiler_types.h \
$(__c_flags) $(modkern_cflags) \
$(basename_flags) $(modname_flags)
Esto generaría un .d archivo con contenido como:
init_task.o: init/init_task.c include/linux/kconfig.h \
include/generated/autoconf.h include/linux/init_task.h \
include/linux/rcupdate.h include/linux/types.h \
...
Entonces el programa anfitrión fixdep se encarga de las otras dos dependencias tomando el depfile y la línea de comando como entrada, luego genera un ..cmd archivo en sintaxis de archivo MAKE, que registra la línea de comando y todos los requisitos previos (incluida la configuración) para un objetivo. Se ve así:
# The command line used to compile the target
cmd_init/init_task.o := gcc -Wp,-MD,init/.init_task.o.d -nostdinc ...
...
# The dependency files
deps_init/init_task.o := \
$(wildcard include/config/posix/timers.h) \
$(wildcard include/config/arch/task/struct/on/stack.h) \
$(wildcard include/config/thread/info/in/task.h) \
...
include/uapi/linux/types.h \
arch/x86/include/uapi/asm/types.h \
include/uapi/asm-generic/types.h \
...
Un ..cmd El archivo se incluirá durante la creación recursiva, proporcionando toda la información de dependencia y ayudando a decidir si reconstruir un objetivo o no.
El secreto detrás de esto es que fixdep analizará el depfile (.d archivo), luego analice todos los archivos de dependencia dentro, busque el texto para todos los CONFIG_ cadenas, conviértalas en el archivo de encabezado vacío correspondiente y agréguelas a los requisitos previos del destino. Cada vez que cambie la configuración, también se actualizará el archivo de encabezado vacío correspondiente, de modo que kbuild pueda detectar ese cambio y reconstruir el destino que depende de él. Debido a que la línea de comando también se registra, es fácil comparar los últimos parámetros de compilación con los actuales.
Mirando hacia el futuro
Kconfig/kbuild permaneció igual durante mucho tiempo hasta que el nuevo mantenedor, Masahiro Yamada, se unió a principios de 2017, y ahora kbuild está nuevamente en desarrollo activo. No se sorprenda si pronto ve algo diferente a lo que se encuentra en este artículo.
