對一個uClinux中的Makefile檔案的簡單分析(ZT)

為了徹底搞清楚linux和uClinux的裝置驅動，我覺得有必要找一份devices.txt的copy。那上面詳細列出了0至255個linux主裝置號的分配情況，以及各種裝置的相應次裝置號。對於，我自己開發非標準的linux裝置非常有用。uClinux的裝置和linux一樣，因此這個文檔同樣適用於uClinux。這個文檔可以從下列網站：http://www.lanana.org/docs/device-list/或者ftp://ftp.kernel.org/pub/linux/docs/device-list/擷取。作為開發的常用手冊，這個文檔有必要列印並儲存下來。

 

我自己為我的開發板上的按鍵寫了一個驅動，我想要像其他linux標準裝置那樣在uClinux啟動起來時，在/dev目錄下有例如/dev/key這樣一個裝置。但是開始我一直搞不清楚為什麼在menuconfig的char device和input core菜單中居然沒有關於鍵盤的選項，但鍵盤驅動又是確實被編譯進系統中了。後來，經過比較linux和uClinux後，我發現問題的關鍵不在於char/目錄下的config.in檔案，也不在於linux-2.4.x/arch/armnommu/Config.in檔案，而在於drivers/char/Makefile檔案。

 

簡要說一下這個檔案，它並不規定menuconfig的char device子功能表的構成，而是規定了drivers/char這個目錄下的檔案的編譯規則。通過在此檔案中，加入一些條件判斷，並根據條件判斷為一些變數賦值，從而達到將特定裝置編譯進uClinux的核心。

 

下面對Makefile中的一些定義進行解釋。

 

編譯目標定義：

 

obj-$(CONFIG_TC) += tc.o的語句是用來定義編譯的目標，是子目錄 Makefile 中最重要的部分。編譯目標定義那些在本子目錄（對於這個Makefile來說，就是針對/linux-2.4.x/drivers/char子目錄）下，需要編譯到 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 有符號輸出。其中的“obj-y +=”表示如果變數為真，那麼就追加什麼；而“obj-y ：=”表示如果變數為真，那麼就等於什麼。

 

這裡需要指出的是，對於編譯目標的定義，存在著兩種格式，分別是老式定義和新式定義。老式定義就是前面 Rules.make 使用的那些變數，新式定義就是 obj-y，obj-m，obj-n 和 obj-。Linux核心推薦使用新式定義，不過由於 Rules.make 不理解新式定義，需要在 Makefile 中的適配段將其轉換成老式定義。

 

另外，需要指出的是linux和uClinux源碼樹中的Makefile分為兩類，一類是由autoconf和automake根據configure.in模板自動產生，另一類是由開發人員自己手工寫的Makefile。所以，對於前者來說，修改檔案中的任何語句或判斷條件，都是徒勞無功的。因為每次建立新的配置或修改以前的配置後，Makefile就會被改寫或重建。要想要通過這種辦法達到自己滿意的編譯配置是不可能的。但後者就不同，由於不是由核心自動產生，因此，不論配置修改多少次，這個檔案都是不會改變的。所以，我們可以通過修改Makefile中的語句或判斷條件，來達到構建我們自己的編譯配置。這一點對添加自己的非標準裝置非常有用。

 

適配段：適配段的作用是將新式定義轉換成老式定義。在下面的例子中，適配段就是將 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）。

 

顯然，由於menuconfig的圖形配置菜單中根本沒有關於鍵盤的選項，因此可以看到在obj-y中並沒有keyboard.o。那麼鍵盤驅動是怎麼編譯進char.o的呢？

 

可以注意到：KEYMAP   =defkeymap.oKEYBD    =pc_keyb.oCONSOLE =console.oSERIAL   =serial.o這四個變數都被賦值。它們分別表示鍵盤碼和掃描碼的映射表、鍵盤驅動、控制台驅動和串口驅動。上面是四個變數的預設值。

 

在下面這一段中，先判斷變數ARCH是否等於sh，如果為真，那麼變數為空白；緊接著下一級邏輯判斷中，判斷變數CONFIG_SH_HP600是否為真，如果為真，那麼鍵盤對應表還是適用預設的映射表（defkeymap.o），但鍵盤驅動就改為hp600_keyb.o和scan_keyb.o，控制台驅動不變。但是要注意串口在這一部分中，並沒有加入判斷語句中，因為串口驅動在下面用obj-$(CONFIG_68328_SERIAL) += 68328serial.o這樣的形勢單獨列出。

 

另外，需要特別指出的是，察看linux或者uClinux各種變數配置的情況，可以看linux-2.4.x/include/linux/autoconf.h、uClinux-dist/config.in以及linux-2.4.x/config.in這三個檔案。

 

 

還有ifeq（..）表示假如等於xxx，那麼xxx；ifneq（..）便是相反意思，表示假如不等於xxx，那麼xxx；ifdef（）表示如果xxx為真，那麼xxx；ifndef（）表示如果xxx為假，那麼xxx。

 

ifeq ($(ARCH),sh)                                     如果ARCH=sh，那麼。。。 KEYMAP   = KEYBD    = CONSOLE = ifeq ($(CONFIG_SH_HP600),y)              如果CONFIG_SH_HP600=y，那麼。。。 KEYMAP   = defkeymap.o KEYBD    = scan_keyb.o hp600_keyb.o CONSOLE = console.o endifendif

 

ifeq ($(ARCH),mips) ifneq ($(CONFIG_PC_KEYB),y)             如果CONFIG_PC_KEYB！=y，那麼。。。    KEYBD    = endifendif

 

ifeq ($(ARCH),m68k)   ifdef CONFIG_AMIGA                        如果CONFIG_AMIGA為真（即變數為y），那麼。。。      KEYBD = amikeyb.o   else      ifndef CONFIG_MAC                     如果CONFIG_AMIGA為假，那麼。。。        KEYBD =      endif   endif   SERIAL   =endif

 

下面這一段很重要。ifndef CONFIG_SUN_KEYBOARD             如果變數為假，那麼判斷變數CONFIG_VT

 

 obj-$(CONFIG_VT) += keyboard.o $(KEYMAP) $(KEYBD) else obj-$(CONFIG_PCI) += keyboard.o $(KEYMAP)endif結果就是CONFIG_SUN_KEYBOARD（SUN公司PC鍵盤）通常為假（我們不會用到），那麼CONFIG_VT是虛擬控制台，通常我們要選擇，就是CONFIG_VT=y，那麼追加keyboard.o、$(KEYMAP)和$(KEYBD)。這兩個變數在最前面有定義：defkeymap.o和pc_keyb.o。因此，標準鍵盤驅動被自動編譯進char.o中，進而被編譯進核心中。

 

所以，我就可以根據這個道理將自己的按鍵驅動自動加入到核心中。下面是我加入的一段語句，完成自動將我自己的按鍵驅動編譯進核心。

 

ifeq($(CONFIG_ARCH_S3C44B0),y)KEYBD = key.oKEYMAP = mykeymap.o       CONSOLE = console.oendif

 

這個Makefile大致就解釋到這兒。其實，不過是拿給自己看的罷了。