启动Linux内核(引导过程)

启动Linux内核(引导过程)

我试图了解 Linux 启动过程:

据我了解,在(由 GRUB 设置)第一阶段,内核(作为压缩映像文件)被加载到内存中并解压缩。

当控制权传递给内核时,这实际上是如何完成的?内核是从 C 源代码编译而来的吗?内核是如何实际执行的。

我已阅读这篇文章,但它似乎没有回答我的问题:

将 Linux 内核映像加载到 RAM 后会发生什么

答案1

内核是从 C 源代码编译而来的吗?内核是如何实际执行的。

此时,内核代码已经编译完毕,并且处于可以直接传递给处理器的形式。的话压缩图像文件不是指 .JPG 或 .GIF 文件之类的图片,而是指记忆影像- 内核实际机器代码的 1:1 表示(解压后)。

在较旧的处理器中,实际的指令字节只是输入到处理器内部逻辑门的硬件矩阵中,称为指令译码器:然后,它将使其他门能够将该特定指令之后的任何数据字节传递到处理器所需的任何部分,并触发任何其他必要的操作。在现代处理器中,通常还有一层软件控制:微码处理器的。

当控制权传递给内核时,这实际上是如何完成的?

这取决于系统的固件+架构。在传统的 x86 BIOS 上,固件和引导加载程序通常是 16 位代码,原则上可以在第一台 IBM PC/AT 上运行:在那里,控制权的传递本质上只是执行从引导加载程序代码到内核代码的跳转指令,并且再也没有回来。

内核代码的第一部分将包括解压缩例程,该例程解压缩内核代码的其余部分,获取 BIOS 留下的任何有用信息(否则这些信息将被覆盖),并将处理器切换到完整的 32 位或 64 位模式。在这个过程中,RAM中的引导加载程序代码可能会被覆盖,因此从内核代码返回到引导加载程序的想法将变得毫无意义。

在具有 UEFI 固件的现代 PC 上,UEFI 规范包括固件/引导加载程序和实际操作系统之间的标准切换协议,但最终它最终是处理器执行跳转指令以从一个代码块(=固件/引导加载程序)到另一个块(=内核的第一部分),并且不打算返回。

相关内容