Linux核心配置系統淺析

 
Linux核心配置系統淺析
[摘錄自http://www-900.ibm.com]
隨著 Linux 作業系統的廣泛應用，特別是 Linux 在嵌入式領域的發展，越來越多的人開始投身到Linux 核心級的開發中。面對日益龐大的 Linux核心原始碼，開發人員在完成自己的核心代碼後，都將面臨著同樣的問題，即如何將原始碼融入到Linux 核心中，增加相應的 Linux 配置選項，並最終被編譯進 Linux 核心。這就需要瞭解 Linux的核心配置系統。

眾所周知，Linux 核心是由分布在全球的 Linux 愛好者共同開發的，Linux核心每天都面臨著許多新的變化。但是，Linux核心的組織並沒有出現混亂的現象，反而顯得非常的簡潔，而且具有很好的擴充性，開發人員可以很方便的向 Linux 核心中增加新的內容。原因之一就是 Linux採用了模組化的核心配置系統，從而保證了核心的擴充性。
本文首先分析了 Linux 核心中的配置系統結構，然後，解釋了 Makefile和設定檔的格式以及配置語句的含義，最後，通過一個簡單的例子--TEST Driver，具體說明如何將自行開發的代碼加入到 Linux核心中。在下面的文章中，不可能解釋所有的功能和命令，只對那些常用的進行解釋，至於那些沒有討論到的，請讀者參考相關的文獻。
1． 配置系統的基本結構
Linux核心的配置系統由三個部分組成，分別是：
1. Makefile：分布在 Linux 核心原始碼中的 Makefile，定義 Linux 核心的編譯規則；
2. 設定檔（config.in）：給使用者提供配置選擇的功能；
3. 組態工具：包括配置命令直譯器（對配置指令碼中使用的配置命令進行解釋）和配置使用者介面

Ncurses 圖形介面以及基於 Xwindows圖形介面的使用者配置介面，各自對應於 Make config、Make menuconfig 和 make xconfig）。
這些組態工具都是使用指令碼語言，如 Tcl/TK、Perl 編寫的（也包含一些用 C編寫的代碼）。本文並不是對配置系統本身進行分析，而是介紹如何使用配置系統。所以，除非是配置系統的維護者，一般的核心開發人員無須瞭解它們的原理，只需要知道如何編寫 Makefile和設定檔就可以。所以，在本文中，我們只對 Makefile和設定檔進行討論。另外，凡是涉及到與具體 CPU 體繫結構相關的內容，我們都以 ARM為例，這樣不僅可以將討論的問題明確化，而且對內容本身不產生影響。
2． Makefile
2.1 Makefile 概述
Makefile的作用是根據配置的情況，構造出需要編譯的源檔案清單，然後分別編譯，並把目標代碼連結到一起，最終形成 Linux 核心二進位檔案。
由於 Linux 核心原始碼是按照樹形結構組織的，所以 Makefile 也被分布在分類樹中。Linux核心中的 Makefile 以及與 Makefile 直接相關的檔案有：
1. Makefile：頂層 Makefile，是整個核心配置、編譯的總體控制檔案。
2. .config：核心設定檔，包含由使用者選擇的配置選項，用來存放核心配置後的結果（如 make config）。
3. arch/*/Makefile：位於各種 CPU 體系目錄下的 Makefile，如arch/arm/Makefile，是針對特定平台的 Makefile。

4. 各個子目錄下的 Makefile：比如 drivers/Makefile，負責所在子目錄下原始碼的管理。
5. Rules.make：規則檔案，被所有的 Makefile 使用。
使用者通過 make config 配置後，產生了 .config。頂層 Makefile 讀入 .config中的配置選擇。頂層 Makefile 有兩個主要的任務：產生 vmlinux檔案和核心模組（module）。為了達到此目的，頂層 Makefile遞迴的進入到核心的各個子目錄中，分別調用位於這些子目錄中的Makefile。至於到底進入哪些子目錄，取決於核心的配置。在頂層 Makefile中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 體繫結構下的 Makefile，這個Makefile
中包含了平台相關的資訊。位於各個子目錄下的 Makefile 同樣也根據 .config給出的配置資訊，構造出當前配置下需要的源檔案清單，並在檔案的最後有 include $(TOPDIR)/Rules.make。
Rules.make 檔案起著非常重要的作用，它定義了所有 Makefile共用的編譯規則。比如，如果需要將本目錄下所有的 c 程式編譯成彙編代碼，需要在 Makefile中有以下的編譯規則：
%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@

有很多子目錄下都有同樣的要求，就需要在各自的 Makefile中包含此編譯規則，這會比較麻煩。而 Linux 核心中則把此類的編譯規則統一放置到 Rules.make中，並在各自的 Makefile 中包含進了 Rules.make（include Rules.make），這樣就避免了在多個 Makefile 中重複同樣的規則。對於上面的例子，在Rules.make 中對應的規則為：
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@

2.2 Makefile 中的變數
頂層 Makefile 定義並向環境中輸出了許多變數，為各個子目錄下的 Makefile傳遞一些資訊。有些變數，比如 SUBDIRS，不僅在頂層 Makefile 中定義並且賦初值，而且在arch/*/Makefile 還作了擴充。
常用的變數有以下幾類：
1） 版本資訊
版本資訊有：VERSION，PATCHLEVEL, SUBLEVEL,EXTRAVERSION，KERNELRELEASE。版本資訊定義了當前核心的版本，比如VERSION=2，PATCHLEVEL=4，SUBLEVEL=19，EXATAVERSION=-rmk7，它們共同構成核心的發行版本KERNELRELEASE：2.4.19-rmk7
2） CPU 體繫結構：ARCH
在頂層 Makefile 的開頭，用 ARCH 定義目標 CPU 的體繫結構，比如 ARCH:=arm等。許多子目錄的 Makefile 中，要根據 ARCH 的定義選擇編譯源檔案的列表。
3） 路徑資訊：TOPDIR, SUBDIRS
TOPDIR 定義了 Linux 核心原始碼所在的根目錄。例如，各個子目錄下的 Makefile 通過$(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定義了一個目錄列表，在編譯核心或模組時，頂層 Makefile 就是根據 SUBDIRS來決定進入哪些子目錄。SUBDIRS 的值取決於核心的配置，在頂層 Makefile 中 SUBDIRS 賦值為kernel drivers mm fs net ipc lib；根據核心的配置情況，在 arch/*/Makefile 中擴充了SUBDIRS 的值，參見4）中的例子。
4） 核心組成資訊：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 核心檔案 vmlinux 是由以下規則產生的：
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）都是用來定義串連產生 vmlinux的目標檔案和庫檔案清單。其中，HEAD在arch/*/Makefile 中定義，用來確定被最先連結進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 根據需要進行擴充。 CORE_FILES 對應著核心的核心檔案，有kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，這些是組成核心最為重要的檔案。
同時，arch/arm/Makefile 對 CORE_FILES 進行了擴充：
# 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中定義的是編譯的通用規則，具體到特定的場合，需要明確給出編譯環境，編譯環境就是在以上的變數中定義的。針對交叉編譯的要求，定義了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-uclibc-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......
CROSS_COMPILE 定義了交叉編譯器首碼 arm-uclibc-，表明所有的交叉編譯工具都是以arm-uclibc- 開頭的，所以在各個交叉編譯器工具之前，都加入了$(CROSS_COMPILE)，以組成一個完整的交叉編譯工具檔案名稱，比如 arm-linux-gcc。
CFLAGS 定義了傳遞給 C 編譯器的參數。
LINKFLAGS 是連結產生 vmlinux 時，由連結器使用的參數。LINKFLAGS 在 arm/*/Makefile
中定義，比如：
# arch/arm/Makefile
LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds
6） 組態變數CONFIG_*
.config 檔案中有許多的組態變數等式，用來說明使用者配置的結果。例如 CONFIG_MODULES=y表明使用者選擇了 Linux 核心的模組功能。
.config 被頂層 Makefile 包含後，就形成許多的組態變數，每個組態變數具有確定的值：y表示本編譯選項對應的核心代碼被靜態編譯進 Linux 核心；m表示本編譯選項對應的核心代碼被編譯成模組；n表示不選擇此編譯選項；如果根本就沒有選擇，那麼組態變數的值為空白。
2.3 Rules.make 變數
前面講過，Rules.make 是編譯規則檔案，所有的 Makefile 中都會包括 Rules.make。Rules.make檔案定義了許多變數，最為重要是那些編譯、連結清單變數。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目錄下需要編譯進 Linux 核心 vmlinux的目標檔案列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目標檔案使用了 EXPORT_SYMBOL輸出符號。
M_OBJS，MX_OBJS：本目錄下需要被編譯成可裝載模組的目標檔案列表。同樣，MX_OBJS 中的 "X"表明目標檔案使用了 EXPORT_SYMBOL 輸出符號。
O_TARGET，L_TARGET：每個子目錄下都有一個 O_TARGET 或 L_TARGET，Rules.make
首先從原始碼編譯產生 O_OBJS 和 OX_OBJS 中所有的目標檔案，然後使用 $(LD) -r把它們連結成一個 O_TARGET 或 L_TARGET。O_TARGET 以 .o 結尾，而 L_TARGET 以 .a 結尾。
2.4 子目錄 Makefile
子目錄 Makefile 用來控制本級目錄以下原始碼的編譯規則。我們通過一個例子來講解子目錄
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 的說明和解釋，由#開始。
b) 編譯目標定義
類似於 obj-$(CONFIG_TC) += tc.o 的語句是用來定義編譯的目標，是子目錄 Makefile中最重要的部分。編譯目標定義那些在本子目錄下，需要編譯到 Linux核心中的目標檔案列表。為了只在使用者選擇了此功能後才編譯，所有的目標定義都融合了對組態變數的判斷。
前面說過，每個組態變數取值範圍是：y，n，m 和空，obj-$(CONFIG_TC) 分別對應著obj-y，obj-n，obj-m，obj-。如果 CONFIG_TC 配置為 y，那麼 tc.o 就進入了 obj-y列表。obj-y 為包含到 Linux 核心 vmlinux 中的目標檔案列表；obj-m為編譯成模組的目標檔案列表；obj-n 和 obj-中的檔案清單被忽略。配置系統就根據這些列表的屬性進行編譯和連結。
export-objs 中的目標檔案都使用了 EXPORT_SYMBOL()定義了公用的符號，以便可裝載模組使用。在 tc.c 檔案的最後部分，有"EXPORT_SYMBOL(search_tc_card);"，表明 tc.o 有符號輸出。
這裡需要指出的是，對於編譯目標的定義，存在著兩種格式，分別是老式定義和新式定義。老式定義就是前面 Rules.make 使用的那些變數，新式定義就是 obj-y，obj-m，obj-n 和 obj-。Linux核心推薦使用新式定義，不過由於 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 的列表中過濾掉 export-objs（tc.o），然後排序並去除重複的檔案名稱。這裡使用到了 GNU Make 的一些特殊功能，具體的含義可參考 Make 的文檔（info make）。
d) include $(TOPDIR)/Rules.make
3． 設定檔
3.1 配置功能概述
除了 Makefile 的編寫，另外一個重要的工作就是把新功能加入到 Linux的配置選項中，提供此項功能的說明，讓使用者有機會選擇此項功能。所有的這些都需要在config.in 檔案中用配置語言來編寫配置指令碼，在 Linux 核心中，配置命令有多種方式：

配置命令 解釋指令碼
Make config, make oldconfig scripts/Configure
Make menuconfig scripts/Menuconfig
Make xconfig scripts/tkparse
以字元介面配置（make config）為例，頂層 Makefile 調用 scripts/Configure， 按照arch/arm/config.in 來進行配置。命令執行完後產生檔案.config，其中儲存著配置資訊。下一次再做 make config 將產生新的 .config 檔案，原
.config 被改名為 .config.old
3.2 配置語言
1） 頂層菜單
mainmenu_name /prompt/ /prompt/是用'或"包圍的字串，'與"的區別是'…'中可使用$引用變數的值。mainmenu_name設定最高層菜單的名字，它只在 make xconfig 時才會顯示。
2） 詢問語句
bool /prompt/ /symbol/
hex /prompt/ /symbol/ /word/
int /prompt/ /symbol/ /word/
string /prompt/ /symbol/ /word/
tristate /prompt/ /symbol/
詢問語句首先顯示一串提示符 /prompt/，等待使用者輸入，並把輸入的結果賦給 /symbol/所代表的組態變數。不同的詢問語句的區別在於它們接受的輸入資料類型不同，比如 bool接受布爾類型（ y 或 n ），hex 接受 16 進位資料。有些詢問語句還有第三個參數/word/，用來給出預設值。

3） 定義語句
define_bool /symbol/ /word/
define_hex /symbol/ /word/
define_int /symbol/ /word/
define_string /symbol/ /word/
define_tristate /symbol/ /word/
不同於詢問語句等待使用者輸入，定義語句顯式的給組態變數 /symbol/ 賦值 /word/。
4） 依賴語句
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/ ...
與詢問語句類似，依賴語句也是定義新的組態變數。不同的是，組態變數/symbol/的取值範圍將依賴於組態變數列表/dep/…。這就意味著：被定義的組態變數所對應功能的取捨取決於依賴列表所對應功能的選擇。以dep_
bool為例，如果/dep/…列表的所有組態變數都取值y，則顯示/prompt/，使用者可輸入任意的值給組態變數/symbol/，不同依賴語句的區別在於它們由依賴條件所產生的取值範圍不同。

5） 選擇語句
choice /prompt/ /word/ /word/
choice 語句首先給出一串挑選清單，供使用者選擇其中一種。比如 Linux for ARM 支援多種基於ARM core 的 CPU，Linux 使用 choice 語句提供一個 CPU 列表，供使用者選擇：
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/分解成前後兩個部分，前部分為對應選擇的提示符，後部分是對應選擇的組態變數。使用者選擇的組態變數為 y，其餘的都為 n。

6） if語句
if [ /expr/ ] ; then
/statement/
...
fi

if [ /expr/ ] ; then
/statement/
...
else
/statement/
...
fi

if 語句對組態變數（或組態變數的組合）進行判斷，並作出不同的處理。判斷條件 /expr/可以是單個組態變數或字串，也可以是帶操作符的運算式。操作符有：=，!=，-o，-a 等。

7） 菜單塊（menu block）語句
mainmenu_option next_comment
comment '…..'
…
endmenu
引入新的菜單。在向核心增加新的功能後，需要相應的增加新的菜單，並在新菜單下給出此項功能的配置選項。Comment 後帶的注釋就是新菜單的名稱。所有歸屬於此菜單的配置選項語句都寫在comment 和 endmenu 之間。

8） Source 語句
source /word/
/word/ 是檔案名稱，source 的作用是調入新的檔案。
3.3 預設配置
Linux
核心支援非常多的硬體平台，對於具體的硬體平台而言，有些配置就是必需的，有些配置就不是必需的。另外，新增加功能的正常運行往往也需要一定的先決條件，針對新功能，必須作相應的配置。因此，特定硬體平台能夠正常運行對應著一個最小的基本配置，這就是預設配置。
Linux 核心中針對每個 ARCH都會有一個預設配置。在向核心代碼增加了新的功能後，如果新功能對於這個 ARCH
是必需的，就要修改此 ARCH 的預設配置。修改方法如下（在 Linux 核心根目錄下）：
1. 備份 .config 檔案
2. cp arch/arm/deconfig .config
3. 修改 .config
4. cp .config arch/arm/deconfig
5. 恢複 .config
如果新增的功能適用於許多的 ARCH，只要針對具體的 ARCH，重複上面的步驟就可以了。
3.4 help file
大家都有這樣的經驗，在配置 Linux核心時，遇到不懂含義的配置選項，可以查看它的協助，從中可得到選擇的建議。下面我們就看看如何給給一個配置選項增加協助資訊。
所有配置選項的協助資訊都在 Documentation/Configure.help 中，它的格式為：
<description>
<variable name>
<help file>
<description> 給出本配置選項的名稱，<variable name> 對應組態變數，<help file>
對應配置協助資訊。在協助資訊中，首先簡單描述此功能，其次說明選擇了此功能後會有什麼效果，不選擇又有什麼效果，最後，不要忘了寫上"如果不清楚，選擇N（或者）Y"，給不知所措的使用者以提示。
4． 執行個體
對於一個開發人員來說，將自己開發的核心代碼加入到 Linux核心中，需要有三個步驟。首先確定把自己開發代碼放入到核心的位置；其次，把自己開發的功能增加到 Linux 核心的配置選項中，使使用者能夠選擇此功能；最後，構建子目錄Makefile，根據使用者的選擇，將相應的代碼編譯到最終產生的 Linux核心中去。下面，我們就通過一個簡單的例子--test driver，結合前面學到的知識，來說明如何向 Linux 核心中增加新的功能。
4.1 目錄結構
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

4.2 設定檔
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 對於核心來說是新的功能，所以首先建立一個菜單 TEST Driver。然後，顯示"TEST support"，等待使用者選擇；接下來判斷使用者是否選擇了 TEST Driver，如果是（CONFIG_TEST=y），則進一步顯示子功能：使用者介面與 CPU功能支援；由於使用者介面功能可以被編譯成核心模組，所以這裡的詢問語句使用了tristate（因為 tristate 的取值範圍包括 y、n 和 m，m 就是對應著模組）。

2） arch/arm/config.in
在檔案的最後加入：source drivers/test/Config.in，將 TEST Driver 子功能的配置納入到Linux 核心的配置中。
4.3 Makefile
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列表中。然後，根據使用者的選擇（具體來說，就是組態變數的取值），構建各自對應的 obj-*列表。由於 TEST Driver 中包一個子目錄 cpu，當CONFIG_TEST_CPU=y（即使用者選擇了此功能）時，需要將 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，使得在使用者選擇 TEST Driver功能後，核心編譯時間能夠進入 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。如何使用者選擇了 TEST Driver，那麼 CONFIG_TEST 和 CONFIG_TEST_CPU 都是 y，test.a 和 test_cpu.a 就都位於DRIVERS-y 列表中，然後又被放置在 DRIVERS 列表中。在前面曾經提到過，Linux 核心檔案vmlinux
的組成中包括 DRIVERS，所以 test.a 和 test_cpu.a 最終可被連結到 vmlinux 中。