突然心血来潮,想自己写个模块,于是就把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源码后会详细解释
linux2.6.29 启动过程详细分析
最新推荐文章于 2019-07-01 15:58:11 发布