linux 引导内存,关于Linux下两种内存引导模式的区别

3．Linux2.6 内核对 Initrd 的处理流程

linux2.6 内核支持两种格式的 initrd，一种是前面第 3 部分介绍的 linux2.4 内核那种传统格式的文件系统镜像－p_w_picpath-initrd，它的制作方法同 Linux2.4 内核的 initrd 一样，其核心文件就是 /linuxrc。另外一种格式的 initrd 是 cpio 格式的，这种格式的 initrd 从 linux2.5 起开始引入，使用 cpio 工具生成，其核心文件不再是 /linuxrc，而是 /init，本文将这种 initrd 称为 cpio-initrd。尽管 linux2.6 内核对 cpio-initrd和 p_w_picpath-initrd 这两种格式的 initrd 均支持，但对其处理流程有着显著的区别，下面分别介绍 linux2.6 内核对这两种 initrd 的处理流程。

cpio-initrd 的处理流程

1． boot loader 把内核以及 initrd 文件加载到内存的特定位置。

2． 内核判断initrd的文件格式，如果是cpio格式。

3． 将initrd的内容释放到rootfs中。

4． 执行initrd中的/init文件，执行到这一点，内核的工作全部结束，完全交给/init文件处理。

p_w_picpath-initrd的处理流程

1． boot loader把内核以及initrd文件加载到内存的特定位置。

2． 内核判断initrd的文件格式，如果不是cpio格式，将其作为p_w_picpath-initrd处理。

3． 内核将initrd的内容保存在rootfs下的/initrd.p_w_picpath文件中。

4． 内核将/initrd.p_w_picpath的内容读入/dev/ram0设备中，也就是读入了一个内存盘中。

5． 接着内核以可读写的方式把/dev/ram0设备挂载为原始的根文件系统。

6． .如果/dev/ram0被指定为真正的根文件系统，那么内核跳至最后一步正常启动。

7． 执行initrd上的/linuxrc文件，linuxrc通常是一个脚本文件，负责加载内核访问根文件系统必须的驱动， 以及加载根文件系统。

8． /linuxrc执行完毕，常规根文件系统被挂载

9． 如果常规根文件系统存在/initrd目录，那么/dev/ram0将从/移动到/initrd。否则如果/initrd目录不存在， /dev/ram0将被卸载。

10． 在常规根文件系统上进行正常启动过程 ，执行/sbin/init。

通过上面的流程介绍可知，Linux2.6内核对p_w_picpath-initrd的处理流程同linux2.4内核相比并没有显著的变化， cpio-initrd的处理流程相比于p_w_picpath-initrd的处理流程却有很大的区别，流程非常简单，在后面的源代码分析中，读者更能体会到处理的简捷。

4．cpio-initrd同p_w_picpath-initrd的区别与优势

没有找到正式的关于cpio-initrd同p_w_picpath-initrd对比的文献，根据笔者的使用体验以及内核代码的分析，总结出如下三方面的区别，这些区别也正是cpio-initrd的优势所在：

cpio-initrd的制作方法更加简单

cpio-initrd的制作非常简单，通过两个命令就可以完成整个制作过程

#假设当前目录位于准备好的initrd文件系统的根目录下

bash# find . | cpio -c -o > ../initrd.img

bash# gzip ../initrd.img

而传统initrd的制作过程比较繁琐，需要如下六个步骤

#假设当前目录位于准备好的initrd文件系统的根目录下

bash# dd if=/dev/zero of=../initrd.img bs=512k count=5

bash# mkfs.ext2 -F -m0 ../initrd.img

bash# mount -t ext2 -o loop ../initrd.img /mnt

bash# cp -r * /mnt

bash# umount /mnt

bash# gzip -9 ../initrd.img

本文不对上面命令的含义作细节的解释，因为本文主要介绍的是linux内核对initrd的处理，对上面命令不理解的读者可以参考相关文档。

注：initrd.img和bootsplash共存的方式：

QUOTE:

Okay, so it seems this is completely wrong. What is required is to copy the splash p_w_picpath file to the rootfs of your initramfs. You don't need to append the p_w_picpath to the compressed initramfs at all. So the correct process is actually:

Build busybox and install it into a directory. We'll call it /mnt/mythbox/busybox.

1. Create a splash data file using a command like this: splash -s -f > splashfile

2. Copy splashfile to the top level of your busybox directory: cp splashfile /mnt/mythbox/busybox/bootsplash Note that the filename in the busybox directory must be bootsplash.

3. Now build your compressed cpio p_w_picpath that will be your 2.6 initramfs. You don't need to append the splash file to the compressed initramfs.

Now it works. This makes sense, too, if you read the bootsplash patch in the init() function. It tries to open the file "/bootsplash". I can see how people thought you still needed to append the file because that's what you did with 2.4. But I'm not sure why the information about placing the file in the root of the rootfs isn't posted somewhere else.

Anyway, this seems to work now. I've verified it with several builds