系列文章目录
深度探索Linux操作系统 ------ 编译过程分析
深度探索Linux操作系统 ------ 构建工具链
深度探索Linux操作系统 ------ 构建内核
深度探索Linux操作系统 ------ 构建initramfs
文章目录
- 系列文章目录
- 前言
- [一、为什么需要 initramfs](#一、为什么需要 initramfs)
- 二、initramfs原理探讨
- 三、构建基本的initramfs
- 四、将硬盘驱动编译为模块
前言
一般而言，桌面、服务器等通用系统都使用 initramfs 。部分嵌入式系统中，也会使用 initramfs，甚至有的使用 initramfs 作为最终的根文件系统。那么什么是 initramfs 呢？很难用一句话将 initramfs 的作用描述清楚，或许可以将 initramfs 定位为内核通往根文件系统的桥梁。
一、为什么需要 initramfs
鸡和蛋的问题：内核要加载这些模块或者运行这些程序才能正确识别根文件系统所在的设备，但是保存这些模块或者程序的根文件系统又存储在这些设备上。
内核开发者们设计了 initramfs 机制。initramfs 是一个临时的文件系统，其中包含了必要的设备如硬盘、网卡、文件系统等的驱动以及加载驱动的工具及其运行环境，比如基本的 C 库，动态库的链接加载器等等。同时，那些处理根文件系统在 RAID 、网络设备上的程序也存放在 initramfs 中。由第三方程序（如 Bootloader ）负责将 initramfs 从硬盘装载进内存。以驱动硬盘为例，内核就不必再从硬盘，而是从已经加载到内存的 initramfs 中获取硬盘控制器等相关驱动了，继而可以驱动硬盘，访问硬盘上的根文件系统，从而解决了前面提到的鸡和蛋的矛盾。
在初始化的最后，内核运行 initramfs 中的 init 程序，该程序将探测硬件设备、加载驱动，挂载真正的文件系统，执行文件系统上的 /sbin/init ，进而切换到真正的用户空间。真正的文件系统挂载后，initramfs 即完成了使命，其占用的内存也会被释放。
二、initramfs原理探讨
在 2.4 以及更早版本的内核中，内核使用的是 initrd 。initrd 是基于ramdisk 技术的，而 ramdisk 就是一个基于内存的块设备，因此 initrd 也具有块设备的一切属性。比如 initrd 容量是固定的，一旦创建 initrd 时设定了一个大小，就不能再进行动态调整。
ramfs 与 ramdisk 有着本质的区别，ramdisk 本质上是基于内存的一个块设备，而 ramfs 是基于缓存的一个文件系统。因此，ramfs 去除了前述块设备的一些限制。比如，ramfs 根据其中包含的文件大小可自由伸缩；增加文件时，自动分配内存；删除文件时，自动释放内存。更重要的是，ramfs 是基于已有的缓存机制，因此不必再像 ramdisk 那样需要和缓存之间进行多余的复制一环。
从 2.6 开始，内核开发人员基于 ramfs 开发了 initramfs 替代 initrd 。
当 2.6 版本的内核引导时，在挂载真正的根文件系统之前，首先将挂载一个名为 rootfs 的文件系统，并将 rootfs 的根作为虚拟文件系统目录树的总根。那么为什么要使用 rootfs 这么一个中间过程呢？原因之一还是为了解决鸡和蛋的问题。内核需要根文件系统上的驱动以及程序来驱动和挂载根文件系统，但是这些驱动和程序有可能没有编译进内核，而在根文件系统上。如果不借助第三方，内核是没有办法挂载真正的根文件系统的。而 rootfs 虽然名称为 rootfs ，但是并不是什么新的文件系统，事实上，其就是一个 ramfs ，只不过换了一个名称。换句话说，rootfs 是在内存中的，内核不需要特殊的驱动就可以挂载 rootfs，所以内核使用 rootfs 作为一个过渡的桥梁。
在挂载了 rootfs 后，内核将 Bootloader 加载到内存中的 initramfs 中打包的文件解压到 rootfs 中，而这些文件中包含了驱动以及挂载真正的根文件系统的工具，内核通过加载这些驱动、使用这些工具，实现了挂载真正的根文件系统。此后，rootfs 也完成了历史使命，被真正的根文件系统覆盖（overmount）。但是 rootfs 作为虚拟文件系统目录树的总根，并不能被卸载。但是这没有关系，前面我们已经谈到了，rootfs 基于 ramfs，删除其中的文件即可释放其占用的空间。
三、构建基本的initramfs
bash
# 1
mkdir initramfs
cd initramfs
# 2
# /vita/initramfs/init
#!/bin/bash
echo "Hello Linux!"
exec /bin/bash
# 3
mkdir bin
cp ../sysroot/bin/bash bin/bash 依赖
bash
vita@baisheng:/vita/initramfs$ ldd bin/bash
libdl.so.2 => /vita/sysroot/lib/libdl.so.2
libgcc_s.so.1 =>/vita/cross-tool/i686-none-linux-gnu/lib/libgcc_s.so.1
libc.so.6 => /vita/sysroot/lib/libc.so.6
vita@baisheng:/vita/initramfs$ ldd lib/libdl.so.2
libc.so.6 => /vita/sysroot/lib/libc.so.6
ld-linux.so.2 => /vita/sysroot/lib/ld-linux.so.2
vita@baisheng:/vita/initramfs$ ldd lib/libc.so.6
ld-linux.so.2 => /vita/sysroot/lib/ld-linux.so.2
vita@baisheng:/vita/initramfs$ ldd lib/ld-linux.so.2
vita@baisheng:/vita/initramfs$ ldd lib/libgcc_s.so.1
libc.so.6 => /vita/sysroot/lib/libc.so.6bash 依赖于libc、libdl 以及 libgcc_s.so.1 ，因此，我们需要在 initramfs 中安装这三个库，以及安装加载动态库的动态加载/链接器。
根据依赖关系可见，libdl 依赖 libc 和动态链接器，libgcc 只依赖 libc ，libc 仅依赖动态链接器，而动态链接器不依赖其他任何库，因此，我们不再需要安装其他库到 initramfs 中。
四、将硬盘驱动编译为模块
1、配置devtmpfs
Linux 从 2.6.18 开始采用 udev ，/dev 目录使用了基于内存的文件系统 tmpfs 管理设备文件。
2009 年初，开发人员又提出了 devtmpfs ，并在同年年底被 Linux 2.6.32 正式收录。内核引导时，devtmpfs 将所有注册的设备在 devtmpfs 中建立相应的设备文件，一旦进入用户空间，在启动 udev 前，就可以将 devtmpfs 挂载到 /dev 目录下。
也就是说，在启动 udev 前，devtmpfs 中已经建立了初步的设备文件，一般启动程序不必再等待 udev 建立设备节点，甚至在某些嵌入式系统上，不再需要 udev 创建设备节点，因为这个基本的 /dev 已经足够，从而缩短了系统的启动时间。同 rootfs 类似，devtmpfs 也不是新设计的文件系统，如果内核配置支持 tmpfs ，那么其就是 tmpfs ；否则，devtmpfs 就是 ramfs，只不过换了一个名字而已。
2、将硬盘控制器驱动配置为模块
接下来重新编译内核和模块。内核和模块可以使用单独的命令分开编译，也可以使用一条 make 命令同时编译内核和模块。编译完成后，将模块暂时安装在 "/vita/sysroot/lib/modules" 目录下。
bash
vita@baisheng:/vita/build/linux-3.7.4$ make bzImage
vita@baisheng:/vita/build/linux-3.7.4$ make modules
vita@baisheng:/vita/build/linux-3.7.4$ make \
INSTALL_MOD_PATH=$SYSROOT modules_install最终安装的硬盘控制器驱动模块包括：
bash
vita@baisheng:/vita$ ls sysroot/lib/modules/3.7.4/kernel/drivers/ata/
ahci.ko ata_piix.ko libahci.ko我们将其复制到 initramfs 中。
3、自动加载硬盘控制器驱动
从 2.6 版内核开始，Linux 采用 udev 管理驱动模块的加载以及设备节点的管理。每当内核发现新的设备，便通过 NETLINK 向用户空间发送新设备事件，该事件中记录了设备的相关信息。用户空间的 udev 服务进程收到内核事件后，根据事件中携带的信息，首先判断该设备的驱动是否已经加载，如果没有，则加载驱动。驱动加载后，内核会再次向用户空间报告发现新设备事件，这时设备已经成功驱动了，并且主次设备号等信息也已经准备好了，udev 收到事件后，或者为设备建立节点，或者执行某些特定的操作。整个过程如图4-19所示。
（1）内核向用户空间发送事件
PC 机上的硬盘控制器，无论是 IDE 接口的，还是 SATA 接口的，一般都是通过 PCI 总线连接到计算机上的。内核在引导时，PCI 子系统将进行初始化，枚举总线上的设备，并尝试为设备匹配驱动；然后将收集到的设备相关信息组织为 uevent 事件；接着调用 kobject_uevent ，通过 NETLINK 将组织好的 uevent 发送到用户空间，通知 udev 有新设备了。简单地讲，内核的工作就是探测并收集设备信息，将其包装到 uevent 事件中，然后发送到用户空间。
事实上，无论是发现新的设备，还是有新的驱动载入，抑或是用户向 sysfs 中的 uevent 写入字符串，内核都将调用函数 kobject_uevent 向用户空间发送事件。
结构体 kobj_uevent_env 用来保存收集到的设备相关信息，所以在函数 kobject_uevent_env 中，首先为 kobj_uevent_env 申请了一块内存，即变量 env 指向的内存，用来临时存放准备发送到用户空间的设备相关信息。
然后向该内存中添加了三个默认的变量，包括 ACTION 、DEVPATH 和 SUBSYSTEM 。 其中 ACTION 指的是热插拔的动作，如 "add"，"remove"，"change" 等。DEVPATH 指的是设备在 sysfs 文件系统中注册的设备路径，比如笔者的硬盘 sda 的 DEVPATH 是 "/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda" 。SUBSYSTEM 一般是指设备所在的总线，比如笔者的硬盘是挂在 PCI 总线上的，因此该变量的值是 "pci"。
pci_uevent 又向 uevent 中追加了 pci class 、 vendor id 、 device id 以及 MODALIAS 等变量，其中 MODALIAS 需要重点关注，其是由设备所在总线、vendor ID、device ID 等相关参数连接而成的一个字符串。在接下来的章节中，读者将看到，用户空间的 udev 恰恰就是根据这个变量为设备匹配驱动模块的。
除了总线外，如果硬盘控制器所属的 class 或者 type 也需要继续向 uevent 中追加变量，则继续调用硬盘控制器所属的 class 或者 type 中的相应的函数，这里不再继续分析了。最终，内核向用户空间发送的 uevent 事件包含的大致的内容如下，其中不同变量之间使用 "\0" 进行分隔。
