内核安装方法的主要的问题是， devfsd 只有在能够访问原来旧类型磁盘上的 /dev 目录下的内容时，才能最好地工作。我们允许访问原来的旧类型设备的典型办法是，在 devfs 自身被安装到 /dev 之前，绑定安装 /dev 到另一个位置（通常是 /dev-state）。
这样就确保了即使在安装了 devfs 以后，也可以在 /dev-state 中访问旧的 /dev，这就允许 devfsd 将该目录用于持久设备存储。理解这点很重要，即如果没有绑定安装的话，/dev 里的旧内容将不可访问，因为在 /dev 安装 devfs 时实际上会覆盖它们。这就是用内核安装 devfs 存在的问题。如果 kernel 在任何其它进程能够启动之前就在 /dev 安装 devfs 文件系统的话，那么我们就没有机会执行绑定安装，/dev 的最初内容也就被完全隐藏。这很不友善，是吗？（想知道更多绑定安装的内容，请参阅本系列的第 3 部分。
最佳解决方案
理想的情况是：我们能在 /sbin/init 一启动时就能拥有完整的设备节点（新类型 和兼容性设备）， 并且有机会在安装 devfs 以前将 /dev 绑定安装到另一位置。但如何才能做到这点？
初始封装器
一个方法是添加一个内核补丁来执行从 /dev 到 /dev-state 的绑定安装。然而，尽管这完全可行，而且也确实很容易执行，手工为您安装的每个 Linux 内核打补丁仍是相当麻烦的。因此，解决 devfs 的“先有鸡还是先有蛋”问题的最好办法，可能就是使用 初始封装器。对于我们这个特别的应用而言，初始封装器就是一个 bash 脚本，它代替 /sbin/init ― 而 真正的 init 则已被重命名为 /sbin/init.system 。简而言之，初始封装器将做以下事情：
#!/bin/bash
mkdir -f /dev-state
mount --bind /dev /dev-state
mount -t devfs none /dev
devfsd /devexec /sbin/init.system
正如您所见，初始封装器所做的第一件事就是确保 /dev-state 存在。然后将 /dev 树绑定安装到 /dev-state，以便可以通过 /dev-state 目录使用 /dev 的内容。然后，在 /dev 之上安装我们的 devfs 文件，然后启动 devfsd ，以便自动在 devfs 中注册我们的兼容性设备。 最后，我们 exec 最初的 /sbin/init ，现在它已被重命名为 /sbin/init.system 。 exec 命令使 init.system 取代正在运行的 bash 进程。这意味着我们的 bash 脚本被终止，而 init.system 继承了标识符为 1 的进程，也就是 init 进程以前被占用的进程标识。当 /sbin/init.system 启动后，系统将正常引导，devfs 现在也已经完全可操作了；通过使用初始封装器，我们不必给内核打补丁，不必修改启动脚本，也不必为只有一半可操作的 devfs 系统而伤脑筋了。 |
