我認為menuconfig是這些目標中最受歡迎的。目標由不同的主機程序進行處理，這些程序由內核提供，并在內核構建過程中生成。一些目標有一個GUI(為了用戶的方便)，而大多數沒有。與kconfig相關的工具和源代碼主要位于scripts/kconfig/在內核源代碼中。我們可以從scripts/kconfig/makefile，有幾個主機程序，包括CONF, mconf，和nconf。除了CONF，它們每個都負責基于GUI的配置目標之一，因此，CONF和他們中的大多數人打交道。

從邏輯上講，Kconfig的基礎結構有兩個部分：一個實現了新語言要定義配置項(請參閱內核源代碼下的Kconfig文件)，而其他配置項則解析Kconfig語言并處理配置操作。

大多數配置目標的內部流程大致相同(如下所示)：

注意，所有配置項都有一個默認值。

第一步讀取源根下的Kconfig文件以構造初始配置數據庫；然后根據此優先級讀取現有配置文件來更新初始數據庫：

• .config
• /lib/Module/$(shell，uname-r)/.config
• /etc/kernel-config
• /boot/config-$(shell，uname-r)
• ARCH_DEFCONFIG
• ARCH/$(ARCH)/Defconfig

如果您正在進行基于GUI的配置，則通過menuconfig或基于命令行的配置oldconfig，數據庫將根據您的自定義進行更新。最后，將配置數據庫轉儲到.config文件中。

但是.config文件不是內核構建的最終素材；這就是為什么syncconfig目標存在。syncconfig以前是一個名為silentoldconfig，但是它不像舊名字說的那樣，所以它被重命名了。此外，由于它是內部使用(而不是為用戶)，它被從列表中刪除。

下面是一個例子syncconfig作用：

syncconfig接受.config作為輸入并輸出許多其他文件，這些文件分為三類：

auto.conf & tristate.conf用于生成文件文本處理。例如，您可能在組件的makefile中看到這樣的語句：

obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o


autoconf.h在C語言源文件中使用。

空頭文件include/config/用于在kbuild期間進行配置依賴項跟蹤，下面將對此進行解釋。

配置之后，我們將知道哪些文件和代碼段沒有編譯。

KBuild

組件式建筑，稱為遞歸制作，是GNU的一種常見方式。制作，使管理一個大型項目。KBuild是遞歸make的一個很好的例子。通過將源文件劃分為不同的模塊/組件，每個組件都由自己的Makefile管理。當您開始構建時，頂級Makefile按正確的順序調用每個組件的makefile，構建組件，并將它們收集到最終的執行程序中。

KBuild指的是不同類型的makefile：

• Makefile位于源根中的頂部makefile。
• .config是內核配置文件。
• ARCH/$(ARCH)/Makefile是拱形Makefile，這是對頂部makefile的補充。
• scripts/Makefile*描述所有kbuild makefile的通用規則。
• 最后，大約有500個Kbuildmakefiles.

頂部的makefile包含archmakefile，讀取.config文件，進入子目錄，調用制作，使中定義的例程的幫助下實現每個組件的makefile。scripts/Makefile*，構建每個中間對象，并將所有中間對象鏈接到vmlinux。核心文件Documentation/kbuild/makefiles.txt描述這些制作文件的所有方面。

例如，讓我們看看在x86-64上如何生成vmlinux：

(插圖是根據理查德·Y·史蒂文(Richard Y.Steven)的博客。經提交人許可后予以更新和使用。

所有.o進入vmlinux的文件首先進入它們自己的built-in.a，這是通過變量表示的。KBUILD_VMLINUX_INIT, KBUILD_VMLINUX_Main, KBUILD_VMLINUX_LIBS，然后收集到vmlinux文件中。

看看如何在Linux內核中實現遞歸make，并借助簡化的Makefile代碼：

# 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

遞歸的配方擴展，例如：

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


這意味著make將進入scripts/Makefile.build繼續建造每一個built-in.a。在.的幫助下scripts/link-vmlinux.sh，vmlinux文件最終位于源根下。

理解vmlinux與bzImage

許多Linux內核開發人員可能不清楚vmlinux和bzImage之間的關系。例如，以下是它們在x86-64中的關系：

源根vmlinux被剝離、壓縮、放入piggy.S，然后將其他對等對象鏈接到arch/x86/boot/compressed/vmlinux。同時，下面生成一個名為setup.bin的文件arch/x86/boot。可能有一個包含重定位信息的可選的第三個文件，具體取決于config_x86_RELOCS.

一個名為build由內核提供，將這兩個(或三個)部分構建到最終的bzImage文件中。

依賴跟蹤

KBuild跟蹤三種依賴關系：

1. 所有的前提文件（*.c和*.h）
2. CONFIG_在所有先決條件文件中使用的選項
3. 用于編譯目標的命令行依賴關系。

第一個很容易理解，但是第二個和第三個呢？內核開發人員經常看到這樣的代碼片段：

#ifdef CONFIG_SMP
__boot_cpu_id = cpu;
#endif

什么時候CONFIG_SMP更改后，這段代碼應該重新編譯。編譯源文件的命令行也很重要，因為不同的命令行可能導致不同的對象文件。

當.C文件通過#include指令，您需要編寫這樣的規則：

main.o: defs.h
recipe...

在管理一個大型項目時，您需要很多這樣的規則；所有這些規則都會乏味。幸運的是，大多數現代C編譯器可以通過查看#include源文件中的行。對于GNU編譯器集合(GCC)，只需添加一個命令行參數：-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)

這將生成一個.D文件的內容如下：

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 \

...

然后主機程序fixdep通過獲取其他兩個依賴項來處理其他兩個依賴項。depfile命令行作為輸入，然后以makefile語法輸出.cmd文件，它記錄目標的命令行和所有先決條件(包括配置)。看起來是這樣的：

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

...

在遞歸生成過程中將包含一個.cmd文件，提供所有依賴項信息，并幫助決定是否重新構建目標。

這背后的秘密是，Fixdep將解析depfile(.d文件)，然后解析其中的所有依賴文件，搜索所有config_string的文本，將它們轉換為相應的空頭文件，并將它們添加到目標的先決條件中。每次配置更改時，相應的空頭文件也將被更新，因此kbuild可以檢測到該更改并重新構建依賴于它的目標。因為還記錄了命令行，所以很容易比較最后的編譯參數和當前的編譯參數。

展望未來

Kconfig/kbuild很長一段時間沒有變化，直到新的維護者山田正一郎(Masahiro Yamada)在2017年初加入，現在KBuild又在積極發展。如果你很快看到了與本文不同的東西，不要感到驚訝。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接

標簽：鎮江 海口 四川 烏海 股票 岳陽 臨沂 紅河