這篇文章給大家分享的是有關(guān)Linux中Kconfig/kbuild的秘密是什么的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

創(chuàng)新互聯(lián)從2013年開(kāi)始，是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元青田做網(wǎng)站,已為上家服務(wù),為青田各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話(huà):18982081108

Kconfig

構(gòu)建內(nèi)核的第一步始終是配置。Kconfig 有助于使 Linux 內(nèi)核高度模塊化和可定制。Kconfig 為用戶(hù)提供了許多配置目標(biāo)：

我認(rèn)為 menuconfig 是這些目標(biāo)中最受歡迎的。這些目標(biāo)由不同的主程序host program處理，這些程序由內(nèi)核提供并在內(nèi)核構(gòu)建期間構(gòu)建。一些目標(biāo)有 GUI（為了方便用戶(hù)），而大多數(shù)沒(méi)有。與 Kconfig 相關(guān)的工具和源代碼主要位于內(nèi)核源代碼中的 scripts/kconfig/ 下。從 scripts/kconfig/Makefile 中可以看到，這里有幾個(gè)主程序，包括 conf、mconf 和 nconf。除了 conf 之外，每個(gè)都負(fù)責(zé)一個(gè)基于 GUI 的配置目標(biāo)，因此，conf 處理大多數(shù)目標(biāo)。

從邏輯上講，Kconfig 的基礎(chǔ)結(jié)構(gòu)有兩部分：一部分實(shí)現(xiàn)一種新語(yǔ)言來(lái)定義配置項(xiàng)（參見(jiàn)內(nèi)核源代碼下的 Kconfig 文件），另一部分解析 Kconfig 語(yǔ)言并處理配置操作。

大多數(shù)配置目標(biāo)具有大致相同的內(nèi)部過(guò)程（如下所示）：

請(qǐng)注意，所有配置項(xiàng)都具有默認(rèn)值。

第一步讀取源代碼根目錄下的 Kconfig 文件，構(gòu)建初始配置數(shù)據(jù)庫(kù)；然后它根據(jù)如下優(yōu)先級(jí)讀取現(xiàn)有配置文件來(lái)更新初始數(shù)據(jù)庫(kù)：

1. .config

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

3. /etc/kernel-config

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

5. ARCH_DEFCONFIG

6. arch/$(ARCH)/defconfig

如果你通過(guò) menuconfig 進(jìn)行基于 GUI 的配置或通過(guò) oldconfig 進(jìn)行基于命令行的配置，則根據(jù)你的自定義更新數(shù)據(jù)庫(kù)。最后，該配置數(shù)據(jù)庫(kù)被轉(zhuǎn)儲(chǔ)到 .config 文件中。

但 .config 文件不是內(nèi)核構(gòu)建的最終素材；這就是 syncconfig 目標(biāo)存在的原因。syncconfig曾經(jīng)是一個(gè)名為 silentoldconfig 的配置目標(biāo)，但它沒(méi)有做到其舊名稱(chēng)所說(shuō)的工作，所以它被重命名。此外，因?yàn)樗枪﹥?nèi)部使用的（不適用于用戶(hù)），所以它已從上述列表中刪除。

以下是 syncconfig 的作用：

syncconfig 將 .config 作為輸入并輸出許多其他文件，這些文件分為三類(lèi)：

• auto.conf ＆ tristate.conf 用于 makefile 文本處理。例如，你可以在組件的 makefile 中看到這樣的語(yǔ)句：obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o。

• autoconf.h 用于 C 語(yǔ)言的源文件。

• include/config/ 下空的頭文件用于 kbuild 期間的配置依賴(lài)性跟蹤。下面會(huì)解釋。

配置完成后，我們將知道哪些文件和代碼片段未編譯。

kbuild

組件式構(gòu)建，稱(chēng)為遞歸 make，是 GNU make 管理大型項(xiàng)目的常用方法。kbuild  是遞歸 make 的一個(gè)很好的例子。通過(guò)將源文件劃分為不同的模塊/組件，每個(gè)組件都由其自己的 makefile 管理。當(dāng)你開(kāi)始構(gòu)建時(shí)，頂級(jí)  makefile 以正確的順序調(diào)用每個(gè)組件的 makefile、構(gòu)建組件，并將它們收集到最終的執(zhí)行程序中。

kbuild 指向到不同類(lèi)型的 makefile：

• Makefile 位于源代碼根目錄的頂級(jí) makefile。

• .config 是內(nèi)核配置文件。

• arch/$(ARCH)/Makefile 是架構(gòu)的 makefile，它用于補(bǔ)充頂級(jí) makefile。

• scripts/Makefile.* 描述所有的 kbuild makefile 的通用規(guī)則。

• 最后，大約有 500 個(gè) kbuild makefile。

頂級(jí) makefile 會(huì)將架構(gòu) makefile 包含進(jìn)去，讀取 .config 文件，下到子目錄，在 scripts/ Makefile.* 中定義的例程的幫助下，在每個(gè)組件的 makefile 上調(diào)用 make，構(gòu)建每個(gè)中間對(duì)象，并將所有的中間對(duì)象鏈接為 vmlinux。內(nèi)核文檔 Documentation/kbuild/makefiles.txt 描述了這些 makefile 的方方面面。

作為一個(gè)例子，讓我們看看如何在 x86-64 上生成 vmlinux：

vmlinux overview

（此插圖基于 Richard Y. Steven 的博客。有過(guò)更新，并在作者允許的情況下使用。）

進(jìn)入 vmlinux 的所有 .o 文件首先進(jìn)入它們自己的 built-in.a，它通過(guò)變量KBUILD_VMLINUX_INIT、KBUILD_VMLINUX_MAIN、KBUILD_VMLINUX_LIBS 表示，然后被收集到 vmlinux 文件中。

在下面這個(gè)簡(jiǎn)化的 makefile 代碼的幫助下，了解如何在 Linux 內(nèi)核中實(shí)現(xiàn)遞歸 make：

# In top Makefilevmlinux: scripts/link-vmlinux.sh $(vmlinux-deps)                +$(call if_changed,link-vmlinux) # Variable assignmentsvmlinux-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.ainit-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.avmlinux-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 的配方recipe被擴(kuò)展開(kāi)是這樣的：

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

這意味著 make 將進(jìn)入 scripts/Makefile.build 以繼續(xù)構(gòu)建每個(gè) built-in.a。在scripts/link-vmlinux.sh 的幫助下，vmlinux 文件最終位于源根目錄下。

vmlinux 與 bzImage 對(duì)比

許多 Linux 內(nèi)核開(kāi)發(fā)人員可能不清楚 vmlinux 和 bzImage 之間的關(guān)系。例如，這是他們?cè)?x86-64 中的關(guān)系：

源代碼根目錄下的 vmlinux 被剝離、壓縮后，放入 piggy.S，然后與其他對(duì)等對(duì)象鏈接到 arch/x86/boot/compressed/vmlinux。同時(shí)，在 arch/x86/boot 下生成一個(gè)名為 setup.bin 的文件。可能有一個(gè)可選的第三個(gè)文件，它帶有重定位信息，具體取決于 CONFIG_X86_NEED_RELOCS 的配置。

由內(nèi)核提供的稱(chēng)為 build 的宿主程序?qū)⑦@兩個(gè)（或三個(gè)）部分構(gòu)建到最終的 bzImage 文件中。

依賴(lài)跟蹤

kbuild 跟蹤三種依賴(lài)關(guān)系：

1. 所有必備文件（*.c 和 *.h）

2. 所有必備文件中使用的 CONFIG_ 選項(xiàng)

3. 用于編譯該目標(biāo)的命令行依賴(lài)項(xiàng)

第一個(gè)很容易理解，但第二個(gè)和第三個(gè)呢？ 內(nèi)核開(kāi)發(fā)人員經(jīng)常會(huì)看到如下代碼：

#ifdef CONFIG_SMP__boot_cpu_id = cpu;#endif

當(dāng) CONFIG_SMP 改變時(shí)，這段代碼應(yīng)該重新編譯。編譯源文件的命令行也很重要，因?yàn)椴煌拿钚锌赡軙?huì)導(dǎo)致不同的目標(biāo)文件。

當(dāng) .c 文件通過(guò) #include 指令使用頭文件時(shí)，你需要編寫(xiě)如下規(guī)則：

main.o: defs.h        recipe...

管理大型項(xiàng)目時(shí)，需要大量的這些規(guī)則；把它們?nèi)繉?xiě)下來(lái)會(huì)很乏味無(wú)聊。幸運(yùn)的是，大多數(shù)現(xiàn)代 C 編譯器都可以通過(guò)查看源文件中的 #include 行來(lái)為你編寫(xiě)這些規(guī)則。對(duì)于 GNU 編譯器集合（GCC），只需添加一個(gè)命令行參數(shù)：-MD depfile

# In scripts/Makefile.libc_flags        = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)     \                 -include $(srctree)/include/linux/compiler_types.h       \                 $(__c_flags) $(modkern_cflags)                           \                 $(basename_flags) $(modname_flags)

這將生成一個(gè) .d 文件，內(nèi)容如下：

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 通過(guò)將 depfile 文件和命令行作為輸入來(lái)處理其他兩個(gè)依賴(lài)項(xiàng)，然后以 makefile 格式輸出一個(gè) ..cmd 文件，它記錄命令行和目標(biāo)的所有先決條件（包括配置）。 它看起來(lái)像這樣：

# The command line used to compile the targetcmd_init/init_task.o := gcc -Wp,-MD,init/.init_task.o.d  -nostdinc ......# The dependency filesdeps_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 \    ...

在遞歸 make 中，..cmd 文件將被包含，以提供所有依賴(lài)關(guān)系信息并幫助決定是否重建目標(biāo)。

這背后的秘密是 fixdep 將解析 depfile（.d 文件），然后解析里面的所有依賴(lài)文件，搜索所有 CONFIG_ 字符串的文本，將它們轉(zhuǎn)換為相應(yīng)的空的頭文件，并將它們添加到目標(biāo)的先決條件。每次配置更改時(shí)，相應(yīng)的空的頭文件也將更新，因此 kbuild 可以檢測(cè)到該更改并重建依賴(lài)于它的目標(biāo)。因?yàn)檫€記錄了命令行，所以很容易比較最后和當(dāng)前的編譯參數(shù)。

感謝各位的閱讀！關(guān)于“Linux中Kconfig/kbuild的秘密是什么”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！