如何編譯一個嵌入式的linux內核

1． 配置系統的基本結構

Linux內核的配置系統由三個部分組成，分別是：

Makefile：分佈在 Linux 內核源代碼中的 Makefile，定義 Linux 內核的編譯規則； 
配置文件（config.in）：給用戶提供配置選擇的功能； 
配置工具：包括配置命令解釋器（對配置腳本中使用的配置命令進行解釋）和配置用戶界面（提供基於字符界面、基於 Ncurses 圖形界面以及基於 Xwindows 圖形界面的用戶配置界面，各自對應於 Make config、Make menuconfig 和 make xconfig）。
這些配置工具都是使用腳本語言，如 Tcl/TK、Perl 編寫的（也包含一些用 C 編寫的代碼）。本文並非對配置系統自己進行分析，而是介紹如何使用配置系統。因此，除非是配置系統的維護者，通常的內核開發者無須瞭解它們的原理，只須要知道如何編寫 Makefile 和配置文件就能夠。

2． Makefile

2.1 Makefile 概述

       Makefile 的做用是根據配置的狀況，構造出須要編譯的源文件列表，而後分別編譯，並把目標代碼連接到一塊兒，最終造成 Linux 內核二進制文件。

      因爲Linux 內核源代碼是按照樹形結構組織的，因此 Makefile 也被分佈在目錄樹中。Linux 內核中的 Makefile 以及與 Makefile 直接相關的文件有：

Makefile：頂層 Makefile，是整個內核配置、編譯的整體控制文件。 
.config：內核配置文件，包含由用戶選擇的配置選項，用來存放內核配置後的結果（如 make config）。 
arch/*/Makefile：位於各類 CPU 體系目錄下的 Makefile，如 arch/arm/Makefile，是針對特定平臺的 Makefile。 
各個子目錄下的 Makefile：好比 drivers/Makefile，負責所在子目錄下源代碼的管理。 
Rules.make：規則文件，被全部的 Makefile 使用。

       用戶經過 make **_defconfig，（針對SMDK2410的默認設置的配置文件位於：arch/arm/configs/s3c2410_defconfig，將這個文件拷貝到根目錄下成爲.config文件。在make menuconfig中加載這個默認的config文件；針對plugD的：arch/arm/configs/plugD_defconfig） 配置後，產生了 .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=18，EXATAVERSION=-rmk7，它們共同構成內核的發行版本KERNELRELEASE：2.4.18-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-linux-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......

CROSS_COMPILE 定義了交叉編譯器前綴 arm-linux-，代表全部的交叉編譯工具都是以 arm-linux- 開頭的，因此在各個交叉編譯器工具以前，都加入了 $(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/，可是隻要有一個配置變量的取值爲n，則/symbol/被強制成n。
不一樣依賴語句的區別在於它們由依賴條件所產生的取值範圍不一樣。

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 內核根目錄下）：

備份 .config 文件 
cp arch/arm/deconfig .config 
修改 .config 
cp .config arch/arm/deconfig 
恢復 .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 中。

Remember don't at a loss and let the brain to calm down when comes questions, so can solve them faster!