网站开发流程怎么写,如何做自己的大淘客网站,电脑虚拟主机,WordPress可以配置163邮箱吗系列文章目录 深度探索Linux操作系统 —— 编译过程分析 深度探索Linux操作系统 —— 构建工具链 深度探索Linux操作系统 —— 构建内核 深度探索Linux操作系统 —— 构建initramfs 文章目录 系列文章目录前言一、为什么需要 initramfs二、initramfs原理探讨三、构建基本的init…
系列文章目录 深度探索Linux操作系统 —— 编译过程分析 深度探索Linux操作系统 —— 构建工具链 深度探索Linux操作系统 —— 构建内核 深度探索Linux操作系统 —— 构建initramfs 文章目录 系列文章目录前言一、为什么需要 initramfs二、initramfs原理探讨三、构建基本的initramfs四、将硬盘驱动编译为模块1、配置devtmpfs2、将硬盘控制器驱动配置为模块3、自动加载硬盘控制器驱动1内核向用户空间发送事件2udev加载驱动和建立设备节点 前言 一般而言桌面、服务器等通用系统都使用 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
# 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 依赖
vitabaisheng:/vita/initramfs$ ldd bin/bashlibdl.so.2 /vita/sysroot/lib/libdl.so.2libgcc_s.so.1 /vita/cross-tool/i686-none-linux-gnu/lib/libgcc_s.so.1libc.so.6 /vita/sysroot/lib/libc.so.6vitabaisheng:/vita/initramfs$ ldd lib/libdl.so.2libc.so.6 /vita/sysroot/lib/libc.so.6ld-linux.so.2 /vita/sysroot/lib/ld-linux.so.2vitabaisheng:/vita/initramfs$ ldd lib/libc.so.6ld-linux.so.2 /vita/sysroot/lib/ld-linux.so.2vitabaisheng:/vita/initramfs$ ldd lib/ld-linux.so.2vitabaisheng:/vita/initramfs$ ldd lib/libgcc_s.so.1libc.so.6 /vita/sysroot/lib/libc.so.6bash 依赖于libc、libdl 以及 libgcc_s.so.1因此我们需要在 initramfs 中安装这三个库以及安装加载动态库的动态加载/链接器。 根据依赖关系可见libdl 依赖 libc 和动态链接器libgcc 只依赖 libclibc 仅依赖动态链接器而动态链接器不依赖其他任何库因此我们不再需要安装其他库到 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” 目录下。
vitabaisheng:/vita/build/linux-3.7.4$ make bzImage
vitabaisheng:/vita/build/linux-3.7.4$ make modules
vitabaisheng:/vita/build/linux-3.7.4$ make \INSTALL_MOD_PATH$SYSROOT modules_install最终安装的硬盘控制器驱动模块包括
vitabaisheng:/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” 进行分隔。 2udev加载驱动和建立设备节点
