udev（五）：devfs

        原创文章，转载请注明出处，谢谢！

        作者：清林，博客名： 飞 空静渡

  <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->

四、回到 /dev

        在 /dev目录里的所有设备文件并不都是对应于当前连接都系统的设备的。相反， /dev目录是在操作系统初始化机器的时候建立的。通过 /dev里的设备文件的名字，我们都可以大概的知道是什么设备。在以前的 Red Hat 9系统里， /dev目录大概保存有 18000个不同的设备条目（真够多的 ：））。这么大量的不同的条目很难让用户确切的知道当前系统中有哪些设备。

        由于那么大量的设备文件存在于 /dev目录里，许多的操作系统（像 unix这些等等）都选择移走这些设备文件而让内核自己来管理 /dev目录，而内核总是确切的知道当前系统里都有些啥设备。它是通过创建一个叫做 devfs的内存文件系统（ ram based filesyste）来实现的， linux也有这个选项，而且也越来越受欢迎。

 

 

五、说说 devfs

        许多的类 unix系统都使用了基因内核 devfs文件系统来解决上面提到的问题。 linux也有 devfs文件系统，对于许多人来说，这直接解决了他们的需要。然而，基于 linux的 devfs的实现仍然存在大量的没有解决的问题。

        在任何时间点里， devfs不仅可以确切的知道有什么设备在当前的系统里，而且也解决了上面说的 /dev目录里存在太多的设备文件的问题。然而， devfs所使用的命名和 LANANA机构的命名是不同的，因此，由于太多的配置文件需要修改，在 devfs系统和静态的 /dev系统之间进行转换就变得比较困难。 devfs的作者试图通过提供一些兼容层来仿真 /dev的名字来解决这个问题。即使 devfs运行于这个兼容模式下， linux在用户空间中还是强迫一个命名机制，这就说第一个 IDE硬盘会被成为 /dev/hda之类的，而在用户空间中对此根本不能够做些什么。通常内核开发人员并不专注用户空间，所以这种命名机制应该移出内核，而让内核人员可以不用专注于这些命名，因为这回浪费很多时间。简而言之，内核不应该去关心用户调用什么样的设备，但使用 devfs，这就不可能实现。

        devfs不允许设备限定于一定的主次设备号，而当前的 devfs的实现仍然使用这些主是由 LANANA分配的主次设备号。 虽然 devfs可以动态的改变这些主次设备号，但至今没有人这么做。

        devfs 也会强迫所有的设备名和命名数据库存储在内核存储空间中（ kernel momory) 。而内核存储空间是常驻的，并不能交换出去。如果有非常大量的设备要加载（如前面说的 4000 个硬盘），那么保存所有的设备名字在内核空间中是不确实际的。 注：《 udev – A Userspace Implementation of devfs 》一文里是这么说的： the overhead of keeping all of the device names in kernel memory is not unsubstantia l. unsubstantial 是不确实际的意思，全面一个 not 就说这是合理的，我这里认为作者写错了，如果不是，请大家指正。

        仅仅在一个静态的 /dev 系统里的在 32 位的 Intel 处理器上，单就检测大范围的主设备号就可令一个开发人员陷入内存消耗光的地步。 4000 个不同硬盘的名字和结构并管理这些名字所带来的开销就可以使用户空间的程序没有内存可用。

 

参考文章：《udev – A Userspace Implementation of devfs》