首先介紹一下__init這個標誌在驅動原始檔中的作用吧。

核心中帶“__”的函式：核心API函式具有這種名稱的，通常都是一些介面的底層函式，應該謹慎使用。實質上，這裡的雙下劃線就是要告訴程式設計師：謹慎呼叫，否則後果自負。以__init為例，__init表明該函式僅在初始化期間使用。在模組被裝載之後，模組裝載器就會將初始化函式扔掉，這樣可以將函式佔用的記憶體釋放出來，已做它用。注意，不要在結束初始化之後仍要使用的函式（或者資料結構）上使用__init、__initdata標記。這裡摘抄網上的一段總結，如下。

__init， __initdata等屬性標誌，是要把這種屬性的程式碼放入目標檔案的.init.text節，資料放入.init.data節──這一過程是通過編譯核心時為相關目標平臺提供了xxx.lds連結指令碼來指導ld完成的。
   對編譯成module的程式碼和資料來說，當模組載入時，__init屬性的函式就被執行;
   對靜態編入核心的程式碼和資料來說，當核心引導時，do_basic_setup()函式呼叫do_initcalls()函式，後者負責所有.init節函式的執行。
   在初始化完成後，用這些關鍵字標識的函式或資料所佔的記憶體會被釋放掉。
1） 所有標識為__init的函式在連結的時候都放在.init.text這個區段內，在這個區段中，函式的擺放順序是和連結的順序有關的，是不確定的。 
2） 所有的__init函式在區段.initcall.init中還儲存了一份函式指標，在初始化時核心會通過這些函式指標呼叫這些__init函式指標，並在整個初始化完成後，釋放整個init區段（包括.init.text，.initcall.init等），注意，這些函式在核心初始化過程中的呼叫順序只和這裡的函式指標的順序有關，和1）中所述的這些函式本身在.init.text區段中的順序無關。 

接下來說明一下如果有多個原始檔來編譯連結組成最終的驅動.ko檔案，那麼他們的Makefile該如何書寫。

核心模組的編譯與應用程式的編譯有些區別，此hello world模組的編譯命令為：

make -C /xxx/xxx/kernel_src/ M=$(PWD) modules

其中/xxx/xxx/kernel_src/ 為已經配置編譯過的核心原始碼路徑，ubuntu下一般在/lib/modules/$(shell uname -r)/build目錄下。

在編寫應用程式時，我們一般都是由多個原始檔組成的，這個時候編譯肯定就不能繼續使用命令列編譯了，就要使用到Makefile。同樣，驅動模組的編譯也需要使用的makefile，下面就是一個在編譯含有多個原始碼檔案的驅動模組時可以參考的Makefile檔案。

1. ifndef CROSS_COMPILE  
2. export CROSS_COMPILE ?=arm-none-linux-gnueabi-  
3. endif  
4. ARCH ?= arm  
5. SRC_DIR := /home/XXX/XXX  
6. OBJ_DIR  := $(SRC_DIR)/obj  
7. PWD := $(shell pwd)  
8. LINUX_SRC ?= /home/XXX/kernel  
9. CFG_INC = -I$(SRC_DIR) \  
10.     -I$(DIR_A) \  
11.     -I$(DIR_B)  
12. CFG_FLAGS += -O2  
13. EXTRA_CFLAGS  += $(C_FLAGS) $(CFG_INC) $(CFG_INC)  
14. obj-m := mymodule.o  
15. mymodule-objs := a.o  
16. mymodule-objs += b.o  
17. mymodule-objs += c.o  
18. modules:  
19.     @make ARCH=$(ARCH) -C $(LINUX_SRC) M=$(PWD) modules  
20. clean:  
21.     @echo "cleaning..."  
22.     rm -f mymodule.ko mymodule.o mymodule.mod.* modules.order Module.symvers  
23.     rm -f $(mymodule-objs)