linux2.6.29 啓動過程詳細分析

linux2.6.29 啓動過程詳細分析 

  突然心血來潮，想自己寫個模塊，於是就把linux2.6.29的啓動過程有分析了一下，整理出來和大家分享下。
linux的啓動大體上可以分幾個步驟：
第一部分 grub部分，內核的加載過程。
這裏總結一下別人的思想，因爲自己沒怎麼看過grub的源碼。
1. Bios執行int 0x19，加載MBR至0x7c00並跳轉執行,這個MBR在我們通常的系統中就是stage1.S(512B)， 位於磁盤的0面0道第一扇區，程序跳到0x7c00處執行
2. stage1執行過程中會加載磁盤0面0道第二扇區的512B的一段程序至0x8000處，就是grub源碼裏stage2/start.S，這裏start.S是stage1_5或是stage2的總入口，它纔是stage1_5或者stage2的真正加載器。
3. 在stage1_5加載之前，stage2是不可能被加載的，因爲stage1並不能識別文件系統
stage1_5究竟被放在哪呢？很多兄弟可能以爲它就是/boot/grub/底下的哪些xxfs_stage1_5文件，但試想一下，要找到boot 分區所在的stage1_5文件，那麼就必須使得stage1具備文件系統識別功能，而stage1_5本身就是文件系統的支撐代碼，它必須加載 stage1_5才能具備這種功能。那麼，我們又回到了那種矛盾體的悖論──要加載stage1_5來找到stage1_5？ 呵呵。

所以用來識別boot分區文件系統的stage1_5不能作爲文件來被stage1讀取，它只能被存放在固定的扇區中。這裏強調"用來識別boot分區文件系統"，那是因爲並不是所有的stage1_5文件都被放在固定扇區的，只有boot分區的文件系統對應的stage1_5纔會被放在固定的扇區中去！比如說，你的boot分區的文件系統是ext2，那麼在安裝GRUB的stage1的時候，e2fs_stage1_5就會被存放至一個固定的扇區集，而其他的如reiserfs_stage1_5就依然作爲文件來存放，以供GRUB使用 root()命令來識別其他的boot分區(那時候，stage2已經被加載了，所以這個不成問題)
最後得出結論，stage1.S被放在0面0道的第1扇區，start.S被放在0面0道的第2扇區，而與boot分區相關的文件系統的xxfs_stage1_5被放在0面0道第3扇區開始的扇區裏，其佔據的扇區數目與該stage1_5文件的大小有關。而其餘的stage1_5以及stage2都作爲文件被存放在boot分區裏。

上面是摘自一位網友的，但是看grub後面的版本比如0.97,好像就不存在所謂的stage1_5了？？這是個疑問。
4. 講完了stage1以及stage1_5的執行流程以及位置關係後，就輪到stage2這個大約110KB左右的mini OS了。stage2的入口是stage2/asm.S，asm.S在設置好c運行環境之後，會調用第一個c函數init_bios_info（stage2/common.c），這個函數在執行一些底層的初始化之後，會調用stage2的main函數cmain（stage2/stage2.c），這樣stage2這個 mini os正式開始運行了！

針對menu.lst和shell這兩種情況，cmain將：
menu.lst: run_menu()(stage2.c)->run_script()(cmdline.c)->find_command->執行命令函數
shell: enter_cmdline()(cmdline.c)->find_command->執行命令函數

殊途同歸，最後都歸結爲命令行的解釋執行
find_command（stage2/cmdline.c）按照menu.lst中或者shell用戶輸入的命令字符串，在一個全局性struct builtin *builtin_table[](stage2/builtin.c)變量中去找到內置命令的函數，然後執行。

值得一提的是grub的shell類似bash的命令補全和命令歷史紀錄。

這裏需要注意的是:stage2要現進入保護模式，把操作系統內核加載到內存，然後回到保護模式，把控制權交給內核。

第二部分 linux內核的啓動
1. 內核會從header.S開始執行，具體爲什麼會從這裏運行，在以後看完grub源碼後會詳細解釋

轉載：http://blog.chinaunix.net/uid-11114210-id-2908501.html