隨著(zhù) Linux 操作系統的廣泛應用，特別是 Linux 在嵌入式領(lǐng)域的發(fā)展，越來(lái)越多的人開(kāi)始投身到 Linux 內核級的開(kāi)發(fā)中。面對日益龐大的 Linux 內核源代碼，開(kāi)發(fā)者在完成自己的內核代碼后，都將面臨著(zhù)同樣的問(wèn)題，即如何將源代碼融入到 Linux 內核中，增加相應的 Linux 配置選項，并最終被編譯進(jìn) Linux 內核。這就需要了解 Linux 的內核配置系統。
眾所周知，Linux 內核是由分布在全球的 Linux 愛(ài)好者共同開(kāi)發(fā)的，Linux 內核每天都面臨著(zhù)許多新的變化。但是，Linux 內核的組織并沒(méi)有出現混亂的現象，反而顯得非常的簡(jiǎn)潔，而且具有很好的擴展性，開(kāi)發(fā)人員可以很方便的向 Linux 內核中增加新的內容。原因之一就是 Linux 采用了模塊化的內核配置系統，從而保證了內核的擴展性。
本文首先分析了 Linux 內核中的配置系統結構，然后，解釋了 Makefile 和配置文件的格式以及配置語(yǔ)句的含義，最后，通過(guò)一個(gè)簡(jiǎn)單的例子--TEST Driver，具體說(shuō)明如何將自行開(kāi)發(fā)的代碼加入到 Linux 內核中。在下面的文章中，不可能解釋所有的功能和命令，只對那些常用的進(jìn)行解釋?zhuān)劣谀切](méi)有討論到的，請讀者參考后面的參考文獻。
Linux內核的配置系統由三個(gè)部分組成，分別是：
這些配置工具都是使用腳本語(yǔ)言，如 Tcl/TK、Perl 編寫(xiě)的（也包含一些用 C 編寫(xiě)的代碼）。本文并不是對配置系統本身進(jìn)行分析，而是介紹如何使用配置系統。所以，除非是配置系統的維護者，一般的內核開(kāi)發(fā)者無(wú)須了解它們的原理，只需要知道如何編寫(xiě) Makefile 和配置文件就可以。所以，在本文中，我們只對 Makefile 和配置文件進(jìn)行討論。另外，凡是涉及到與具體 CPU 體系結構相關(guān)的內容，我們都以 ARM 為例，這樣不僅可以將討論的問(wèn)題明確化，而且對內容本身不產(chǎn)生影響。
Makefile 的作用是根據配置的情況，構造出需要編譯的源文件列表，然后分別編譯，并把目標代碼鏈接到一起，最終形成 Linux 內核二進(jìn)制文件。
由于 Linux 內核源代碼是按照樹(shù)形結構組織的，所以 Makefile 也被分布在目錄樹(shù)中。Linux 內核中的 Makefile 以及與 Makefile 直接相關(guān)的文件有：
用戶(hù)通過(guò) make config 配置后，產(chǎn)生了 .config。頂層 Makefile 讀入 .config 中的配置選擇。頂層 Makefile 有兩個(gè)主要的任務(wù)：產(chǎn)生 vmlinux 文件和內核模塊（module）。為了達到此目的，頂層 Makefile 遞歸的進(jìn)入到內核的各個(gè)子目錄中，分別調用位于這些子目錄中的 Makefile。至于到底進(jìn)入哪些子目錄，取決于內核的配置。在頂層 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 體系結構下的 Makefile，這個(gè) Makefile 中包含了平臺相關(guān)的信息。
位于各個(gè)子目錄下的 Makefile 同樣也根據 .config 給出的配置信息，構造出當前配置下需要的源文件列表，并在文件的最后有 include $(TOPDIR)/Rules.make。
Rules.make 文件起著(zhù)非常重要的作用，它定義了所有 Makefile 共用的編譯規則。比如，如果需要將本目錄下所有的 c 程序編譯成匯編代碼，需要在 Makefile 中有以下的編譯規則：
%.s: %.c$(CC) $(CFLAGS) -S $< -o $@
有很多子目錄下都有同樣的要求，就需要在各自的 Makefile 中包含此編譯規則，這會(huì )比較麻煩。而 Linux 內核中則把此類(lèi)的編譯規則統一放置到 Rules.make 中，并在各自的 Makefile 中包含進(jìn)了 Rules.make（include Rules.make），這樣就避免了在多個(gè) Makefile 中重復同樣的規則。對于上面的例子，在 Rules.make 中對應的規則為：
%.s: %.c$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@
頂層 Makefile 定義并向環(huán)境中輸出了許多變量，為各個(gè)子目錄下的 Makefile 傳遞一些信息。有些變量，比如 SUBDIRS，不僅在頂層 Makefile 中定義并且賦初值，而且在 arch/*/Makefile 還作了擴充。
常用的變量有以下幾類(lèi)：
1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定義了當前內核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它們共同構成內核的發(fā)行版本KERNELRELEASE：2.4.18-rmk7
2） CPU 體系結構：ARCH
在頂層 Makefile 的開(kāi)頭，用 ARCH 定義目標 CPU 的體系結構，比如 ARCH:=arm 等。許多子目錄的 Makefile 中，要根據 ARCH 的定義選擇編譯源文件的列表。
3） 路徑信息：TOPDIR, SUBDIRS
TOPDIR 定義了 Linux 內核源代碼所在的根目錄。例如，各個(gè)子目錄下的 Makefile 通過(guò) $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定義了一個(gè)目錄列表，在編譯內核或模塊時(shí)，頂層 Makefile 就是根據 SUBDIRS 來(lái)決定進(jìn)入哪些子目錄。SUBDIRS 的值取決于內核的配置，在頂層 Makefile 中 SUBDIRS 賦值為 kernel drivers mm fs net ipc lib；根據內核的配置情況，在 arch/*/Makefile 中擴充了 SUBDIRS 的值，參見(jiàn)4）中的例子。
4） 內核組成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 內核文件 vmlinux 是由以下規則產(chǎn)生的：
vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs $(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o --start-group $(CORE_FILES) $(DRIVERS) $(NETWORKS) $(LIBS) --end-group -o vmlinux |
可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 組成的。這些變量（如 HEAD）都是用來(lái)定義連接生成 vmlinux 的目標文件和庫文件列表。其中，HEAD在arch/*/Makefile 中定義，用來(lái)確定被最先鏈接進(jìn) vmlinux 的文件列表。比如，對于 ARM 系列的 CPU，HEAD 定義為：
HEAD := arch/arm/kernel/head-$(PROCESSOR).o arch/arm/kernel/init_task.o |
表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被鏈接到 vmlinux 中。PROCESSOR 為 armv 或 armo，取決于目標 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在頂層 Makefile 中定義，并且由 arch/*/Makefile 根據需要進(jìn)行擴充。 CORE_FILES 對應著(zhù)內核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，這些是組成內核最為重要的文件。同時(shí)，arch/arm/Makefile 對 CORE_FILES 進(jìn)行了擴充：
# arch/arm/Makefile # If we have a machine-specific directory, then include it in the build. MACHDIR := arch/arm/mach-$(MACHINE) ifeq ($(MACHDIR),$(wildcard $(MACHDIR))) SUBDIRS += $(MACHDIR) CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES) endif HEAD := arch/arm/kernel/head-$(PROCESSOR).o arch/arm/kernel/init_task.o SUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe CORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES) LIBS := arch/arm/lib/lib.a $(LIBS) |
5） 編譯信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定義的是編譯的通用規則，具體到特定的場(chǎng)合，需要明確給出編譯環(huán)境，編譯環(huán)境就是在以上的變量中定義的。針對交叉編譯的要求，定義了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-linux- CC = $(CROSS_COMPILE)gcc LD = $(CROSS_COMPILE)ld ...... |
CROSS_COMPILE 定義了交叉編譯器前綴 arm-linux-，表明所有的交叉編譯工具都是以 arm-linux- 開(kāi)頭的，所以在各個(gè)交叉編譯器工具之前，都加入了 $(CROSS_COMPILE)，以組成一個(gè)完整的交叉編譯工具文件名，比如 arm-linux-gcc。
CFLAGS 定義了傳遞給 C 編譯器的參數。
LINKFLAGS 是鏈接生成 vmlinux 時(shí)，由鏈接器使用的參數。LINKFLAGS 在 arm/*/Makefile 中定義，比如：
# arch/arm/Makefile LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds |
6） 配置變量CONFIG_*
.config 文件中有許多的配置變量等式，用來(lái)說(shuō)明用戶(hù)配置的結果。例如 CONFIG_MODULES=y 表明用戶(hù)選擇了 Linux 內核的模塊功能。
.config 被頂層 Makefile 包含后，就形成許多的配置變量，每個(gè)配置變量具有確定的值：y 表示本編譯選項對應的內核代碼被靜態(tài)編譯進(jìn) Linux 內核；m 表示本編譯選項對應的內核代碼被編譯成模塊；n 表示不選擇此編譯選項；如果根本就沒(méi)有選擇，那么配置變量的值為空。
前面講過(guò)，Rules.make 是編譯規則文件，所有的 Makefile 中都會(huì )包括 Rules.make。Rules.make 文件定義了許多變量，最為重要是那些編譯、鏈接列表變量。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目錄下需要編譯進(jìn) Linux 內核 vmlinux 的目標文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
M_OBJS，MX_OBJS：本目錄下需要被編譯成可裝載模塊的目標文件列表。同樣，MX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
O_TARGET，L_TARGET：每個(gè)子目錄下都有一個(gè) O_TARGET 或 L_TARGET，Rules.make 首先從源代碼編譯生成 O_OBJS 和 OX_OBJS 中所有的目標文件，然后使用 $(LD) -r 把它們鏈接成一個(gè) O_TARGET 或 L_TARGET。O_TARGET 以 .o 結尾，而 L_TARGET 以 .a 結尾。
子目錄 Makefile 用來(lái)控制本級目錄以下源代碼的編譯規則。我們通過(guò)一個(gè)例子來(lái)講解子目錄 Makefile 的組成：
# # Makefile for the linux kernel. # # All of the (potential) objects that export symbols. # This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'. export-objs := tc.o # Object file lists. obj-y := obj-m := obj-n := obj- := obj-$(CONFIG_TC) += tc.o obj-$(CONFIG_ZS) += zs.o obj-$(CONFIG_VT) += lk201.o lk201-map.o lk201-remap.o # Files that are both resident and modular: remove from modular. obj-m := $(filter-out $(obj-y), $(obj-m)) # Translate to Rules.make lists. L_TARGET := tc.a L_OBJS := $(sort $(filter-out $(export-objs), $(obj-y))) LX_OBJS := $(sort $(filter $(export-objs), $(obj-y))) M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m))) MX_OBJS := $(sort $(filter $(export-objs), $(obj-m))) include $(TOPDIR)/Rules.make |
a) 注釋
對 Makefile 的說(shuō)明和解釋?zhuān)?開(kāi)始。
b) 編譯目標定義
類(lèi)似于 obj-$(CONFIG_TC) += tc.o 的語(yǔ)句是用來(lái)定義編譯的目標，是子目錄 Makefile 中最重要的部分。編譯目標定義那些在本子目錄下，需要編譯到 Linux 內核中的目標文件列表。為了只在用戶(hù)選擇了此功能后才編譯，所有的目標定義都融合了對配置變量的判斷。
前面說(shuō)過(guò)，每個(gè)配置變量取值范圍是：y，n，m 和空，obj-$(CONFIG_TC) 分別對應著(zhù) obj-y，obj-n，obj-m，obj-。如果 CONFIG_TC 配置為 y，那么 tc.o 就進(jìn)入了 obj-y 列表。obj-y 為包含到 Linux 內核 vmlinux 中的目標文件列表；obj-m 為編譯成模塊的目標文件列表；obj-n 和 obj- 中的文件列表被忽略。配置系統就根據這些列表的屬性進(jìn)行編譯和鏈接。
export-objs 中的目標文件都使用了 EXPORT_SYMBOL() 定義了公共的符號，以便可裝載模塊使用。在 tc.c 文件的最后部分，有 "EXPORT_SYMBOL(search_tc_card);"，表明 tc.o 有符號輸出。
這里需要指出的是，對于編譯目標的定義，存在著(zhù)兩種格式，分別是老式定義和新式定義。老式定義就是前面 Rules.make 使用的那些變量，新式定義就是 obj-y，obj-m，obj-n 和 obj-。Linux 內核推薦使用新式定義，不過(guò)由于 Rules.make 不理解新式定義，需要在 Makefile 中的適配段將其轉換成老式定義。
c) 適配段
適配段的作用是將新式定義轉換成老式定義。在上面的例子中，適配段就是將 obj-y 和 obj-m 轉換成 Rules.make 能夠理解的 L_TARGET，L_OBJS，LX_OBJS，M_OBJS，MX_OBJS。
L_OBJS := $(sort $(filter-out $(export-objs), $(obj-y))) 定義了 L_OBJS 的生成方式：在 obj-y 的列表中過(guò)濾掉 export-objs（tc.o），然后排序并去除重復的文件名。這里使用到了 GNU Make 的一些特殊功能，具體的含義可參考 Make 的文檔（info make）。
d) include $(TOPDIR)/Rules.make
除了 Makefile 的編寫(xiě)，另外一個(gè)重要的工作就是把新功能加入到 Linux 的配置選項中，提供此項功能的說(shuō)明，讓用戶(hù)有機會(huì )選擇此項功能。所有的這些都需要在 config.in 文件中用配置語(yǔ)言來(lái)編寫(xiě)配置腳本，
在 Linux 內核中，配置命令有多種方式：
| 配置命令 | 解釋腳本 |
| Make config, make oldconfig | scripts/Configure |
| Make menuconfig | scripts/Menuconfig |
| Make xconfig | scripts/tkparse |
以字符界面配置（make config）為例，頂層 Makefile 調用 scripts/Configure， 按照 arch/arm/config.in 來(lái)進(jìn)行配置。命令執行完后產(chǎn)生文件 .config，其中保存著(zhù)配置信息。下一次再做 make config 將產(chǎn)生新的 .config 文件，原 .config 被改名為 .config.old
1） 頂層菜單
mainmenu_name /prompt/ /prompt/ 是用'或"包圍的字符串，'與"的區別是'…'中可使用$引用變量的值。mainmenu_name 設置最高層菜單的名字，它只在 make xconfig 時(shí)才會(huì )顯示。
2） 詢(xún)問(wèn)語(yǔ)句
bool /prompt/ /symbol/ hex /prompt/ /symbol/ /word/ int /prompt/ /symbol/ /word/ string /prompt/ /symbol/ /word/ tristate /prompt/ /symbol/ |
詢(xún)問(wèn)語(yǔ)句首先顯示一串提示符 /prompt/，等待用戶(hù)輸入，并把輸入的結果賦給 /symbol/ 所代表的配置變量。不同的詢(xún)問(wèn)語(yǔ)句的區別在于它們接受的輸入數據類(lèi)型不同，比如 bool 接受布爾類(lèi)型（ y 或 n ），hex 接受 16 進(jìn)制數據。有些詢(xún)問(wèn)語(yǔ)句還有第三個(gè)參數 /word/，用來(lái)給出缺省值。
3） 定義語(yǔ)句
define_bool /symbol/ /word/ define_hex /symbol/ /word/ define_int /symbol/ /word/ define_string /symbol/ /word/ define_tristate /symbol/ /word/ |
不同于詢(xún)問(wèn)語(yǔ)句等待用戶(hù)輸入，定義語(yǔ)句顯式的給配置變量 /symbol/ 賦值 /word/。
4） 依賴(lài)語(yǔ)句
dep_bool /prompt/ /symbol/ /dep/ ... dep_mbool /prompt/ /symbol/ /dep/ ... dep_hex /prompt/ /symbol/ /word/ /dep/ ... dep_int /prompt/ /symbol/ /word/ /dep/ ... dep_string /prompt/ /symbol/ /word/ /dep/ ... dep_tristate /prompt/ /symbol/ /dep/ ... |
與詢(xún)問(wèn)語(yǔ)句類(lèi)似，依賴(lài)語(yǔ)句也是定義新的配置變量。不同的是，配置變量/symbol/的取值范圍將依賴(lài)于配置變量列表/dep/ …。這就意味著(zhù)：被定義的配置變量所對應功能的取舍取決于依賴(lài)列表所對應功能的選擇。以dep_bool為例，如果/dep/ …列表的所有配置變量都取值y，則顯示/prompt/，用戶(hù)可輸入任意的值給配置變量/symbol/，但是只要有一個(gè)配置變量的取值為n，則/symbol/被強制成n。
不同依賴(lài)語(yǔ)句的區別在于它們由依賴(lài)條件所產(chǎn)生的取值范圍不同。
5） 選擇語(yǔ)句
choice /prompt/ /word/ /word/ |
choice 語(yǔ)句首先給出一串選擇列表，供用戶(hù)選擇其中一種。比如 Linux for ARM 支持多種基于 ARM core 的 CPU，Linux 使用 choice 語(yǔ)句提供一個(gè) CPU 列表，供用戶(hù)選擇：
choice 'ARM system type' "Anakin CONFIG_ARCH_ANAKIN Archimedes/A5000 CONFIG_ARCH_ARCA5K Cirrus-CL-PS7500FE CONFIG_ARCH_CLPS7500 …… SA1100-based CONFIG_ARCH_SA1100 Shark CONFIG_ARCH_SHARK" RiscPC |
Choice 首先顯示 /prompt/，然后將 /word/ 分解成前后兩個(gè)部分，前部分為對應選擇的提示符，后部分是對應選擇的配置變量。用戶(hù)選擇的配置變量為 y，其余的都為 n。
6） if語(yǔ)句
if [ /expr/ ] ; then /statement/ ... fi if [ /expr/ ] ; then /statement/ ... else /statement/ ... fi |
if 語(yǔ)句對配置變量（或配置變量的組合）進(jìn)行判斷，并作出不同的處理。判斷條件 /expr/ 可以是單個(gè)配置變量或字符串，也可以是帶操作符的表達式。操作符有：=，!=，-o，-a 等。
7） 菜單塊（menu block）語(yǔ)句
mainmenu_option next_comment comment '…..' … endmenu |
引入新的菜單。在向內核增加新的功能后，需要相應的增加新的菜單，并在新菜單下給出此項功能的配置選項。Comment 后帶的注釋就是新菜單的名稱(chēng)。所有歸屬于此菜單的配置選項語(yǔ)句都寫(xiě)在 comment 和 endmenu 之間。
8） Source 語(yǔ)句
source /word/
/word/ 是文件名，source 的作用是調入新的文件。
Linux 內核支持非常多的硬件平臺，對于具體的硬件平臺而言，有些配置就是必需的，有些配置就不是必需的。另外，新增加功能的正常運行往往也需要一定的先決條件，針對新功能，必須作相應的配置。因此，特定硬件平臺能夠正常運行對應著(zhù)一個(gè)最小的基本配置，這就是缺省配置。
Linux 內核中針對每個(gè) ARCH 都會(huì )有一個(gè)缺省配置。在向內核代碼增加了新的功能后，如果新功能對于這個(gè) ARCH 是必需的，就要修改此 ARCH 的缺省配置。修改方法如下（在 Linux 內核根目錄下）：
如果新增的功能適用于許多的 ARCH，只要針對具體的 ARCH，重復上面的步驟就可以了。
大家都有這樣的經(jīng)驗，在配置 Linux 內核時(shí)，遇到不懂含義的配置選項，可以查看它的幫助，從中可得到選擇的建議。下面我們就看看如何給給一個(gè)配置選項增加幫助信息。
所有配置選項的幫助信息都在 Documentation/Configure.help 中，它的格式為：
<description> <variable name> <help file> |
<description> 給出本配置選項的名稱(chēng)，<variable name> 對應配置變量，<help file> 對應配置幫助信息。在幫助信息中，首先簡(jiǎn)單描述此功能，其次說(shuō)明選擇了此功能后會(huì )有什么效果，不選擇又有什么效果，最后，不要忘了寫(xiě)上"如果不清楚，選擇 N（或者）Y"，給不知所措的用戶(hù)以提示。
對于一個(gè)開(kāi)發(fā)者來(lái)說(shuō)，將自己開(kāi)發(fā)的內核代碼加入到 Linux 內核中，需要有三個(gè)步驟。首先確定把自己開(kāi)發(fā)代碼放入到內核的位置；其次，把自己開(kāi)發(fā)的功能增加到 Linux 內核的配置選項中，使用戶(hù)能夠選擇此功能；最后，構建子目錄 Makefile，根據用戶(hù)的選擇，將相應的代碼編譯到最終生成的 Linux 內核中去。下面，我們就通過(guò)一個(gè)簡(jiǎn)單的例子--test driver，結合前面學(xué)到的知識，來(lái)說(shuō)明如何向 Linux 內核中增加新的功能。
test driver 放置在 drivers/test/ 目錄下：
$cd drivers/test $tree . |-- Config.in |-- Makefile |-- cpu | |-- Makefile | `-- cpu.c |-- test.c |-- test_client.c |-- test_ioctl.c |-- test_proc.c |-- test_queue.c `-- test |-- Makefile `-- test.c |
1） drivers/test/Config.in
# # TEST driver configuration # mainmenu_option next_comment comment 'TEST Driver' bool 'TEST support' CONFIG_TEST if [ "$CONFIG_TEST" = "y" ]; then tristate 'TEST user-space interface' CONFIG_TEST_USER bool 'TEST CPU ' CONFIG_TEST_CPU fi endmenu |
由于 test driver 對于內核來(lái)說(shuō)是新的功能，所以首先創(chuàng )建一個(gè)菜單 TEST Driver。然后，顯示 "TEST support"，等待用戶(hù)選擇；接下來(lái)判斷用戶(hù)是否選擇了 TEST Driver，如果是（CONFIG_TEST=y），則進(jìn)一步顯示子功能：用戶(hù)接口與 CPU 功能支持；由于用戶(hù)接口功能可以被編譯成內核模塊，所以這里的詢(xún)問(wèn)語(yǔ)句使用了 tristate（因為 tristate 的取值范圍包括 y、n 和 m，m 就是對應著(zhù)模塊）。
2） arch/arm/config.in
在文件的最后加入：source drivers/test/Config.in，將 TEST Driver 子功能的配置納入到 Linux 內核的配置中。
1）drivers/test/Makefile
# drivers/test/Makefile # # Makefile for the TEST. # SUB_DIRS := MOD_SUB_DIRS := $(SUB_DIRS) ALL_SUB_DIRS := $(SUB_DIRS) cpu L_TARGET := test.a export-objs := test.o test_client.o obj-$(CONFIG_TEST) += test.o test_queue.o test_client.o obj-$(CONFIG_TEST_USER) += test_ioctl.o obj-$(CONFIG_PROC_FS) += test_proc.o subdir-$(CONFIG_TEST_CPU) += cpu include $(TOPDIR)/Rules.make clean: for dir in $(ALL_SUB_DIRS); do make -C $$dir clean; done rm -f *.[oa] .*.flags |
drivers/test 目錄下最終生成的目標文件是 test.a。在 test.c 和 test-client.c 中使用了 EXPORT_SYMBOL 輸出符號，所以 test.o 和 test-client.o 位于 export-objs 列表中。然后，根據用戶(hù)的選擇（具體來(lái)說(shuō)，就是配置變量的取值），構建各自對應的 obj-* 列表。由于 TEST Driver 中包一個(gè)子目錄 cpu，當 CONFIG_TEST_CPU=y（即用戶(hù)選擇了此功能）時(shí)，需要將 cpu 目錄加入到 subdir-y 列表中。
2）drivers/test/cpu/Makefile
# drivers/test/test/Makefile # # Makefile for the TEST CPU # SUB_DIRS := MOD_SUB_DIRS := $(SUB_DIRS) ALL_SUB_DIRS := $(SUB_DIRS) L_TARGET := test_cpu.a obj-$(CONFIG_test_CPU) += cpu.o include $(TOPDIR)/Rules.make clean: rm -f *.[oa] .*.flags |
3）drivers/Makefile
…… subdir-$(CONFIG_TEST) += test …… include $(TOPDIR)/Rules.make |
在 drivers/Makefile 中加入 subdir-$(CONFIG_TEST)+= test，使得在用戶(hù)選擇 TEST Driver 功能后，內核編譯時(shí)能夠進(jìn)入 test 目錄。
4）Makefile
…… DRIVERS-$(CONFIG_PLD) += drivers/pld/pld.o DRIVERS-$(CONFIG_TEST) += drivers/test/test.a DRIVERS-$(CONFIG_TEST_CPU) += drivers/test/cpu/test_cpu.a DRIVERS := $(DRIVERS-y) …… |
在頂層 Makefile 中加入 DRIVERS-$(CONFIG_TEST) += drivers/test/test.a 和 DRIVERS-$(CONFIG_TEST_CPU) += drivers/test/cpu/test_cpu.a。如何用戶(hù)選擇了 TEST Driver，那么 CONFIG_TEST 和 CONFIG_TEST_CPU 都是 y，test.a 和 test_cpu.a 就都位于 DRIVERS-y 列表中，然后又被放置在 DRIVERS 列表中。在前面曾經(jīng)提到過(guò)，Linux 內核文件 vmlinux 的組成中包括 DRIVERS，所以 test.a 和 test_cpu.a 最終可被鏈接到 vmlinux 中。
聯(lián)系客服
