追随Linux内核启动的脚步

卢鹏 

        一、背景介绍

       之前通过几个简单的小程序，简要分析了计算机和操作系统工作的相关情况。现在我们再构造一个小系统MenuOS，观察linux内核是怎么启动的。本文主要用gdb跟踪调试，分析内核从start_kernel到init进程启动的过程。

       先来了解一些关于linux内核相关知识。linux内核是一个一体化内核系统，“内核”指的是一个提供硬件抽象层、磁盘及文件系统控制、多任务等功能的系统软件。一个内核不是一套完整的操作系统。一套基于Linux内核的完整操作系统叫作Linux操作系统，或是GNU/Linux。

       二、实验过程

       首先来简单看一下我们的MenuOS。进入LinuxKernel，启动内核：（系统里面有好几个版本的内核，我用的是3.18.6）

       

       这样，一个小系统就启动了。这个系统很简单，有三个命令：help、version、quit。当然，可以自己增加更多功能。不过，这不在本文范围之内。MenuOS已经足够我们来分析一个内核启动的来龙去脉。

      下面就开始正式分析。

       要分析内核启动，就不能让内核代码一次性加载完。所以我们要冻结系统的加载。用这条指令帮助stop： qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S。-s是创建一个gdb server（下面会用到），而-S是表示冻结在启动时冻结cpu。

   

      这样，我们就能用gdb设置断点，一步步的调试，观察cpu启动了。

        紧接着是打开gdb调试窗口：

       打开gdb之后，输入命令 file linux-3.18.6/vmlinux，这表示在gdb界面中targe remote之前加载符号表。再输入target remote：1234 建立gdb和gdbserver之间的连接。参数1234是自己设置的。然后设置第一个断点：break start_kernel，也就是在start_kernel处设置了断点。

       这时可以用'c'来启动系统：

       系统就继续运行起来了。用list可以看到系统代码加载到了哪个地方：

       我们很清晰的看到系统加载到我们设置的断点start_kernel处。用相同的方法可以在rest_init处设置断点：

       依次设置断点，我们就能很清晰的看到了一个内核的加载。当然断点的设置可以更精确，也可以略粗糙。

       三、心得体会

       虽然分析了内核加载的过程，但其中几点没有讲清楚：比如start_kernel是什么概念、rest_init到底是什么进程、1号进程是怎么来的、idle进程等等。下面说说我的理解。

       从某种意义上，函数start_kernel就好像一般可执行程序中的主函数main，系统进入这个函数之前进行了一些最低限度的初始化工作。即对内存管理和各子系统的数据结构初始化。在内核初始化函数start_kernel执行到最后，就是调用rest_init函数，这个函数的主要任务就是创建并启动内核线程init。

       简单的说idle是一个进程，其pid号为 0。其前身是系统创建的第一个进程，也是唯一一个没有通过fork()产生的进程。有多少处理器单元，就有多少idle进程。系统的空闲时间，其实就是指idle进程的"运行时间"。init进程(pid=1)是除了idle进程(pid=0)之外另一个比较特殊的进程，它是Linux内核开始建立起进程概念时第一个通过kernel_thread产生的进程，其开始在内核态执行，然后通过一个系统调用，开始执行用户空间的程序。在start_kernel()完成Linux内核的初始化工作后，这个工作包括初始化页表，初始化中断向量表，初始化系统时间等。继而调用 fork()，创建了第一个用户进程。

       

       

注：1、实验环境是网易云课堂提供的实验楼

        2、MenuOS系统源代码MenuOS