Erkundung des Linux-Kernels:Die Geheimnisse von Kconfig/kbuild

.config

/lib/modules/$(shell,uname -r)/.config

/etc/kernel-config

/boot /config-$(shell,uname -r)

ARCH_DEFCONFIG

arch/$(ARCH)/defconfig

Wenn Sie eine GUI-basierte Konfiguration über menuconfig durchführen oder befehlszeilenbasierte Konfiguration über oldconfig , wird die Datenbank gemäß Ihrer Anpassung aktualisiert. Schließlich wird die Konfigurationsdatenbank in die .config-Datei ausgegeben.

Aber die .config-Datei ist nicht das letzte Futter für die Kernel-Erstellung; Aus diesem Grund ist die syncconfig Ziel existiert. syncconfig war früher ein Konfigurationsziel namens silentoldconfig , aber es macht nicht das, was der alte Name sagt, also wurde es umbenannt. Da es für den internen Gebrauch bestimmt ist (nicht für Benutzer), wurde es aus der Liste gestrichen.

Hier ist eine Illustration dessen, was syncconfig tut:

syncconfig nimmt .config als Eingabe und gibt viele andere Dateien aus, die in drei Kategorien fallen:

• auto.conf &tristate.conf werden für die Makefile-Textverarbeitung verwendet. Beispielsweise können Sie Anweisungen wie diese im Makefile einer Komponente sehen: 
  

  obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o

• autoconf.h wird in Quelldateien der Sprache C verwendet.
• Leere Header-Dateien unter include/config/ werden für das Tracking der Konfigurationsabhängigkeit während kbuild verwendet, was unten erklärt wird.

Nach der Konfiguration wissen wir, welche Dateien und Codeteile nicht kompiliert sind.

kbuild

Komponentenweises Erstellen, genannt rekursives Make , ist ein gängiger Weg für GNU make um ein großes Projekt zu leiten. Kbuild ist ein gutes Beispiel für rekursives Make. Durch die Aufteilung der Quelldateien in verschiedene Module/Komponenten wird jede Komponente von ihrem eigenen Makefile verwaltet. Wenn Sie mit dem Erstellen beginnen, ruft ein Top-Makefile das Makefile jeder Komponente in der richtigen Reihenfolge auf, erstellt die Komponenten und sammelt sie in der endgültigen Ausführung.

Kbuild bezieht sich auf verschiedene Arten von Makefiles:

• Makefile ist das oberste Makefile, das sich im Quellverzeichnis befindet.
• .config ist die Kernel-Konfigurationsdatei.
• arch/$(ARCH)/Makefile ist das Arch-Makefile, das die Ergänzung zum Top-Makefile ist.
• scripts/Makefile.* beschreibt allgemeine Regeln für alle kbuild-Makefiles.
• Schließlich gibt es etwa 500 kbuild-Makefiles .

Das oberste Makefile enthält das Arch-Makefile, liest die .config-Datei, steigt in Unterverzeichnisse ab und ruft make auf auf dem Makefile jeder Komponente mit Hilfe von Routinen, die in scripts/Makefile.* definiert sind , baut jedes Zwischenobjekt auf und verknüpft alle Zwischenobjekte mit vmlinux. Das Kernel-Dokument Documentation/kbuild/makefiles.txt beschreibt alle Aspekte dieser Makefiles.

Sehen wir uns als Beispiel an, wie vmlinux auf x86-64 erstellt wird:

Alle .o Dateien, die in vmlinux aufgenommen werden, gehen zuerst in ihre eigene built-in.a , was über Variablen KBUILD_VMLINUX_INIT angegeben wird , KBUILD_VMLINUX_MAIN , KBUILD_VMLINUX_LIBS , werden dann in der vmlinux-Datei gesammelt.

Sehen Sie sich mit Hilfe des vereinfachten Makefile-Codes an, wie rekursives make im Linux-Kernel implementiert ist:

# 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

Das rekursive Make-Rezept wird erweitert, zum Beispiel:

make -f scripts/Makefile.build obj=init need-builtin=1

Das bedeutet machen geht in scripts/Makefile.build um die Arbeit zum Erstellen jedes built-in.a fortzusetzen . Mit Hilfe von scripts/link-vmlinux.sh , die vmlinux-Datei befindet sich schließlich im Quellverzeichnis.

Vmlinux vs. bzImage verstehen

Vielen Linux-Kernel-Entwicklern ist die Beziehung zwischen vmlinux und bzImage möglicherweise nicht klar. Hier ist zum Beispiel ihre Beziehung in x86-64:

Das Quell-Root-vmlinux wird entfernt, komprimiert und in piggy.S abgelegt , dann mit anderen Peer-Objekten in arch/x86/boot/compressed/vmlinux verknüpft . In der Zwischenzeit wird unter arch/x86/boot eine Datei namens setup.bin erstellt . Abhängig von der Konfiguration von CONFIG_X86_NEED_RELOCS kann es eine optionale dritte Datei mit Umzugsinformationen geben .

Ein Host-Programm namens build , bereitgestellt vom Kernel, baut diese zwei (oder drei) Teile in die endgültige bzImage-Datei ein.

Abhängigkeitsverfolgung

Kbuild verfolgt drei Arten von Abhängigkeiten:

1. Alle erforderlichen Dateien (sowohl *.c und *.h )
2. CONFIG_ Optionen, die in allen vorausgesetzten Dateien verwendet werden
3. Befehlszeilenabhängigkeiten, die zum Kompilieren des Ziels verwendet werden

Das erste ist leicht zu verstehen, aber was ist mit dem zweiten und dritten? Kernel-Entwickler sehen oft Codeteile wie diese:

#ifdef CONFIG_SMP
__boot_cpu_id = cpu;
#endif

Wenn CONFIG_SMP Änderungen, sollte dieser Codeabschnitt neu kompiliert werden. Die Befehlszeile zum Kompilieren einer Quelldatei ist ebenfalls wichtig, da unterschiedliche Befehlszeilen zu unterschiedlichen Objektdateien führen können.

Wenn eine .c file verwendet eine Header-Datei über ein #include Direktive müssen Sie eine Regel wie diese schreiben:

main.o: defs.h
	recipe...

Wenn Sie ein großes Projekt verwalten, benötigen Sie viele dieser Regeln. sie alle zu schreiben, wäre mühsam und langweilig. Glücklicherweise können die meisten modernen C-Compiler diese Regeln für Sie schreiben, indem sie sich das #include ansehen Zeilen in der Quelldatei. Für die GNU Compiler Collection (GCC) muss lediglich ein Befehlszeilenparameter hinzugefügt werden:-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)

Dies würde ein .d erzeugen Datei mit Inhalt wie:

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 \
 ...

Dann das Wirtsprogramm fixdep kümmert sich um die anderen beiden Abhängigkeiten, indem es das depfile nimmt und Befehlszeile als Eingabe, dann Ausgabe einer ..cmd Datei in Makefile-Syntax, die die Befehlszeile und alle Voraussetzungen (einschließlich der Konfiguration) für ein Ziel aufzeichnet. Es sieht so aus:

# 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 \
  ...

Eine ..cmd -Datei wird während des rekursiven Erstellens eingefügt, liefert alle Abhängigkeitsinformationen und hilft bei der Entscheidung, ob ein Ziel neu erstellt werden soll oder nicht.

Das Geheimnis dahinter ist das fixdep parst das depfile (.d Datei), parsen Sie dann alle darin enthaltenen Abhängigkeitsdateien, durchsuchen Sie den Text nach allen CONFIG_ Zeichenfolgen, konvertieren Sie sie in die entsprechende leere Header-Datei und fügen Sie sie den Voraussetzungen des Ziels hinzu. Jedes Mal, wenn sich die Konfiguration ändert, wird auch die entsprechende leere Header-Datei aktualisiert, sodass kbuild diese Änderung erkennen und das davon abhängige Ziel neu erstellen kann. Da auch die Befehlszeile aufgezeichnet wird, ist es einfach, die letzten und aktuellen Kompilierungsparameter zu vergleichen.

Vorausblick

Kconfig/kbuild blieb lange Zeit gleich, bis Anfang 2017 der neue Betreuer Masahiro Yamada hinzukam, und jetzt wird kbuild wieder aktiv weiterentwickelt. Seien Sie nicht überrascht, wenn Sie bald etwas anderes als in diesem Artikel sehen.