突然心血来潮，想自己写个模块，于是就把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源码后会详细解释
阅读(171) | 评论(0) | 转发(0) |
