Linux内核启动分析

作者：奋斗的白杨

注：原创作品，转载请注明出处

《Linux内核分析》 MOOC课程http://mooc.study.163.com/course/USTC-1000029000

一、构建自己的实验环境

1. 在Linux14.04上配置32位程序的运行环境。

apt-get install lib32z1 lib32ncurses5-dev lib32bz2-1.0 libc6-dev-i386

2. 安装Qemu

apt-get install qemu # install QEMU
ln -s /usr/bin/qemu-system-i386 /usr/bin/qemu

3. 搭建MenuOS运行环境

# 下载内核源代码编译内核
cd ~/LinuxKernel/
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.18.6.tar.xz
xz -d linux-3.18.6.tar.xz
tar -xvf linux-3.18.6.tar
cd linux-3.18.6
make i386_defconfig
make # 一般要编译很长时间，少则20分钟多则数小时
 
# 制作根文件系统
cd ~/LinuxKernel/
mkdir rootfs
git clone https://github.com/mengning/menu.git  # 如果被墙，可以使用附件menu.zip 
cd menu
gcc -o init linktable.c menu.c test.c -m32 -static –lpthread
cd ../rootfs
cp ../menu/init ./
find . | cpio -o -Hnewc |gzip -9 > ../rootfs.img
 
# 启动MenuOS系统
cd ~/LinuxKernel/
qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img

4. 上面编译的Linux内核没有debug信息，需要在原来配置的基础上重新配置，使之携带调试信息。

make menuconfig

然后重新make，生成带调试信息的Kernel。

二、使用GDB跟踪调试内核

第一步：用QEMU加载Linux3.18的内核

qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S # 关于-s和-S选项的说明：
# -S freeze CPU at startup (use ’c’ to start execution)
# -s shorthand for -gdb tcp::1234 若不想使用1234端口，则可以使用-gdb tcp:xxxx来取代-s选项

其中-S选项是开启了一个gdb server。

关于qemu一些选项的详细说明，可以使用qemu --help来查看。

第二步：使用GDB进行调试跟踪。

关于GDB的使用，可以参考下面的表：

命令	解释	示例
file <文件名>	加载被调试的可执行程序文件。 因为一般都在被调试程序所在目录下执行GDB，因而文本名不需要带路径。	(gdb) file gdb-sample
r	Run的简写，运行被调试的程序。 如果此前没有下过断点，则执行完整个程序；如果有断点，则程序暂停在第一个可用断点处。	(gdb) r
c	Continue的简写，继续执行被调试程序，直至下一个断点或程序结束。	(gdb) c
b <行号> b <函数名称> b *<函数名称> b *<代码地址> d [编号]	b: Breakpoint的简写，设置断点。两可以使用“行号”“函数名称”“执行地址”等方式指定断点位置。 其中在函数名称前面加“*”符号表示将断点设置在“由编译器生成的prolog代码处”。如果不了解汇编，可以不予理会此用法。 d: Delete breakpoint的简写，删除指定编号的某个断点，或删除所有断点。断点编号从1开始递增。	(gdb) b 8 (gdb) b main (gdb) b *main (gdb) b *0x804835c (gdb) d
s, n	s: 执行一行源程序代码，如果此行代码中有函数调用，则进入该函数； n: 执行一行源程序代码，此行代码中的函数调用也一并执行。 s 相当于其它调试器中的“Step Into (单步跟踪进入)”； n 相当于其它调试器中的“Step Over (单步跟踪)”。 这两个命令必须在有源代码调试信息的情况下才可以使用（GCC编译时使用“-g”参数）。	(gdb) s (gdb) n
si, ni	si命令类似于s命令，ni命令类似于n命令。所不同的是，这两个命令（si/ni）所针对的是汇编指令，而s/n针对的是源代码。	(gdb) si (gdb) ni
p <变量名称>	Print的简写，显示指定变量（临时变量或全局变量）的值。	(gdb) p i (gdb) p nGlobalVar
display ... undisplay <编号>	display，设置程序中断后欲显示的数据及其格式。 例如，如果希望每次程序中断后可以看到即将被执行的下一条汇编指令，可以使用命令 “display /i $pc” 其中 $pc 代表当前汇编指令，/i 表示以十六进行显示。当需要关心汇编代码时，此命令相当有用。 undispaly，取消先前的display设置，编号从1开始递增。	(gdb) display /i $pc (gdb) undisplay 1
i	Info的简写，用于显示各类信息，详情请查阅“help i”。	(gdb) i r
q	Quit的简写，退出GDB调试环境。	(gdb) q
help [命令名称]	GDB帮助命令，提供对GDB名种命令的解释说明。 如果指定了“命令名称”参数，则显示该命令的详细说明；如果没有指定参数，则分类显示所有GDB命令，供用户进一步浏览和查询。	(gdb) help display

　

我们新打开一个Terminal

gdb
（gdb）file linux-3.18.6/vmlinux # 在gdb界面中targe remote之前加载符号表
（gdb）target remote:1234 # 建立gdb和gdbserver之间的连接,按c 让qemu上的Linux继续运行
（gdb）break start_kernel # 断点的设置可以在target remote之前，也可以在之后

设置好断点后，按c[Enter]，让程序执行到断点位置。

使用list命令查看start_kernel附近的代码。

在rest_init处，我们设置第二个断点。

此处是start_kernel最后调用的一个函数。

三、Linux内核启动分析

  ● 计算机的启动过程概述
      ○ x86 CPU启动的第一个动作CS:EIP=FFFF:0000H（换算为物理地址为000FFFF0H，因为16位CPU有20根地址线)，即BIOS程序的位置。http://wenku.baidu.com/view/4e5c49eb172ded630b1cb699.html
      ○ BIOS例行程序检测完硬件并完成相应的初始化之后就会寻找可引导介质，找到后把引导程序加载到指定内存区域后，就把控制权交给了引导程序。这里一般是把硬盘的第一个扇区MBR和活动分区的引导程序加载到内存（即加载BootLoader），加载完整后把控制权交给BootLoader。
      ○ 引导程序BootLoader开始负责操作系统初始化，然后起动操作系统。启动操作系统时一般会指定kernel、initrd和root所在的分区和目录，比如root (hd0,0)，kernel (hd0,0)/bzImage root=/dev/ram init=/bin/ash，initrd (hd0,0)/myinitrd4M.img
      ○ 内核启动过程包括start_kernel之前和之后，之前全部是做初始化的汇编指令，之后开始C代码的操作系统初始化，最后执行第一个用户态进程init。

      ○ 一般分两阶段启动，先是利用initrd的内存文件系统，然后切换到硬盘文件系统继续启动。initrd文件的功能主要有两个：1、提供开机必需的但kernel文件(即vmlinuz)没有提供的驱动模块(modules) 2、负责加载硬盘上的根文件系统并执行其中的/sbin/init程序进而将开机过程持续下去

四、道生一、一生二、二生三、三生万物

当Power on PC时，BIOS的代码开始执行，然后是Linux初始化的代码，这其中大约很长一段时间Linux都没有进程这一概念，但是这不影响CPU执行它的二进制代码。如果不是多任务以及进程调度的需要，Linux内核可以一直这样走下去。
但是因为多任务的需求，Linux必须能支持任务这一特性，任务即进程，或者更简单地说由task_struct对象实例所代表的一段代码的集合，用以完成特定的任务。所以Linux内核初始化过程中必须为进程以及进程调度做准备。

init_task进程在Linux中属于一个比较特殊的进程，它是内核开发者人为制造出来的，而不是其他进程通过do_fork来完成。init_task对象的初始化在内核代码中由下面代码来完成：

<arch/x86/kernel/init_task.c>
struct task_struct init_task = INIT_TASK(init_task);

如果仔细考察INIT_TASK宏的细节，会发现很多有趣的东西，比如inti_task所对应的内核栈，在INIT_TASK宏中由下列代码指定：

.stack        = &init_thread_info

可以猜想init_task进程的内核栈一定是通过静态方式分配的，事实上也的确如此：

<arch/x86/kernel/init_task.c>
union thread_union init_thread_union __init_task_data =
    { INIT_THREAD_INFO(init_task) };

init_thread_info定义中的__init_task_data表明该内核栈所在的区域位于内核映像的init data区，我们可以通过编译完内核后所产生的System.map来看到该变量及其对应的逻辑地址：
root@build-server:/boot# cat System.map-3.1.6 | grep init_thread_union
ffffffff81a00000 D init_thread_union
这意味着init_task.stack = 0xffffffff81a00000.

Linux在无进程概念的情况下将一直从初始化部分的代码执行到start_kernel，然后再到其最后一个函数调用rest_init。

从rest_init开始，Linux开始产生进程，因为init_task是静态制造出来的，pid=0，它试图将从最早的汇编代码一直到start_kernel的执行都纳入到init_task进程上下文中。在rest_init函数中，内核将通过下面的代码产生第一个真正的进程(pid=1):

<init/main.c>
static noinline void __init_refok rest_init(void)
{
    ...
    kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
    ...
    cpu_idle();
}

kernel_init函数最有意思的地方在于它会通过调用kernel_execve来执行根文件系统下的/sbin/init文件(所以此前系统根文件系统必须已经就绪)，kernel_execve对用户空间程序/sbin/init的调用发起自int $0x80，这是个从内核空间发起的系统调用，与call_usermodehelper函数本质上是完全一样的。

而此时init_task的任务基本上已经完全结束了，它将沦落为一个idle task，事实上在更早前的sched_init（）函数中，通过init_idle(current, smp_processor_id())函数的调用就已经把init_task初始化成了一个idle task，init_idle函数的第一个参数current就是&init_task，在init_idle中将会把init_task加入到cpu的运行队列中，这样当运行队列中没有别的就绪进程时，init_task（也就是idle task)将会被调用，它的核心是一个while(1)循环，在循环中它将会调用schedule函数以便在运行队列中有新进程加入时切换到该新进程上。

五、Init进程分析

init process 是 Linux 系统的第一个用户态进程，那自然没有父亲。它是由 Linux 内核直接启动的。

start_kernel()是内核的汇编与Ｃ语言的交接点，在该函数以前，内核的代码都是用汇编写的，完成一些最基本的初始化与环境内核代码载入内存并解压缩（现在的内核一般都经过压缩），CPU 的最基本初始化，为 C 代码的运行设置环境（C 代码的运行是有的，比如 stack 的设置等）。这里一个不太确切的比喻是 start_kernel()就像是 C 代码中的 main()。我们知道对应用程序员是他的入口，但实际上程序的入口是被包在了Ｃ库中，在链接阶段，linker 会把它链接入你的程序中。而它的任务中有一项就是为
行环境。main()中的 argc，argv 等都不是平白无故来的，都是在调用 main()以前的代码做的准备。

在 start_kernel()中 Linux 将完成整个系统的内核初始化。内核初始化的最后一步就是启动 init 进程这个所有进程的祖先。

参考：init进程详解