前言:我覺得我的文章相對來說都是比較淺顯的。一些初學者可以看看,對於高手來說,如果你們不吝啬時間的話,希望也能幫我看看,指點一下其中的錯誤。這也是我到這裡來和大家交流的目的。
閱讀Linux內核啟動代碼的直接動力是我想編寫RTL8019AS的網卡驅動程序(2.4.18內核只支持了CS8900A)。既然要寫驅動,我就想知道它是怎麼樣被加載的,好奇心驅使我先去搞定這個問題。
拿到2.4.18的軟件包,一萬多個文件,我不知怎麼下手。所幸手頭有這麼三件工具助我入門:
1,一塊移植好linux的開發板,通過它可以看到linux啟動過程打印的消息。
2, google,網上關於linux的資料真是太多了!!!
3, Windows文件搜索引擎,通過它可以知道在那些文件中打印出那些消息。
很快,我就找到了linux啟動的總的入口,/arch/arm/boot/compressed/head.s。
head.s完成的工作主要是底層寄存器、MMU的一些設定以及kernel的解壓縮。匯編文件中調用的C代碼大多位於該目錄下misc.c文件,比如decompress_kernel。
當然,這部分不是重點,head執行完畢以後就跳到start_kernel(),這才是我們的重點所在,這個函數位於文件/init/main.c中。這個文件是啟動的主線!!!
在start_kernel中,依次執行各個初始話函數,這裡具體我沒有看,一直到最後rest_init(),在這個函數裡啟動了一個init線程,而主線程自己則進入了IDLE狀態。所以我們關心一下init線程做了什麼事情,看文件最後init函數。
在這個函數裡面,先lock_kernel,然後調用do_basic_setup,在這個函數裡面又是一堆的初始化,有一個函數要引起我們的注意:do_initcalls。看看它干了什麼:(這之後的東西在下文文件系統中講解)
static void __init do_initcalls(void)
{
initcall_t *call;
call = &__initcall_start;
do {
(*call)( );
call++;
} while (call < &__initcall_end);
/* Make sure there is no pending stuff from the initcall sequence */
flush_scheduled_tasks();
}
很難相信,我們關心的外圍模塊的驅動就是被這一段程序加載的。怎麼回事?我們慢慢來看:
首先看__initcall_start和__initcall_end,找遍了所有C代碼,沒有它們的定義。後來在vmlinux-armv.lds.in文件中找到了它們:
__initcall_start = .;
*(.initcall.init)
__initcall_end = .;
這個文件是和link相關的文件,它決定代碼在load環境中的位置,就好比ADS中的scf文件。我們還是先看.initcall.init的含義吧,它在/include/linux/init.h中定義:
#define __init_call __attribute__ ((unused,__section__ (".initcall.init ")))
參考GCC說明,這段話的意思就是說所有以__init_call前綴定義的函數在鏈接過程中都放到名字為.initcall.init的段(section)裡面。OK,有點味道了,也就是說,如果我們給一個函數冠以__init_call,那麼它在編譯鏈接的時候就會放到.initcall.init這個段裡面。而上面這段循環所做的事情就很清楚了,它從段的首地址開始,依次執行每一個函數,直到段尾為止。
這個時候,我們應該在想,那些要注冊的外圍模塊的初始化程序是不是都是定義成__init_call類型的呢?正如我們所料,查看各個模塊我們會發現其初始化函數x會被定義成為module_init(x),在/include/linux/init.h中它定義如下:
#define module_init(x) __initcall(x);
#define __initcall(fn) static initcall_t __initcall_##fn __init_call = fn
這段代碼說module_init(x)等價於__initcall(x),而__initcall(x)表示函數x是靜態的具有__init_call性質的函數(這裡名字比較多,容易看亂),因此在鏈接時,它會被放在.initcall.init段中。只要x函數運行起來了,那就可以注冊設備、中斷入口、中斷服務函數了。接下來的事情就好辦了。
搞清出設備如何被加載以後,我們還需要知道另外一個問題:怎樣把一個模塊的驅動程序加載到內核裡面呢?SO簡單,make menuconfig,把對應設備打開。但是能不能再具體一點呢,我們做這麼一個改動,怎麼映射到編譯&鏈接過程呢。我這個人就是喜歡找麻煩,因此又在網上搜啊搜,而且用了最笨的方法,看看make menuconfig前後那些文件的修改日期發生了變化。最終還是找到了一點,/scripts下的文件是用來支持各種config模式的(當然包括menuconfig),核心代碼在Kconfig中。在每個驅動設備的文件夾下(比如net,mtd)都有一個叫config.in的文件,這些文件定義了我們在menuconfig畫面中看到的目錄結構&選項。
眼睛看到的畫面總歸都是虛的,這些改動究竟反映到了哪裡去了呢?兩個文件:./config和/include/linux/ autoconf.h。我們做完menuconfig以後,所有改動就反映到了這兩個文件中,這兩個文件的內容是一致的。在我們做編譯的過程中,頂層的makefile文件從autoconf.h文件中讀取各項宏定義然後傳遞給子一層的makefile,這些makefile根據宏定義選擇那些.o文件被鏈接進來加到內核中。
好了,知道這些我就知道怎麼給8019添加驅動了,yy一12下一頁