linux 设备管理机制[转]

                                        -----thks 天曜

1. 早期策略

    在linux下，设备资源的管理主要是通过系统对设备文件的维护来完成的。设备文件不同于一般文件，它不包括任何数据，只是操作系统与外部设备交流交互的一个通道。

   Linux的设备管理策略已经经历了三次变革。在最早期的Linux版本中，设备文件只是一些普通的带特殊属性的文件，由mknod命令创建，挂载于/dev下，并由普通的文件系统统一管理。随着Linux支持的硬件种类越来越多，/dev树 愈趋膨胀，往往数百个特殊文件才足够表示所有的硬件设备。不仅如此，在多数时间中，大部分特殊文件甚至不会映射到系统中存在的设备上，但考虑到我们可能会 在将来添加这些新的硬件，又不得不保留他们的设备文件。这不仅浪费了大量的空间，而且极易造成管理混乱，为设备检测带来额外的时间消耗。

   随着Devfs在2.4内核引入，上述问题得到了一定改善。Devfs也叫设备文件系统（Device Filesystem），旨在提供一个新的方式管理设备文件。Devfs不同于传统意义上的文件系统，它是一个虚拟文件系统。Devfs会为所有向它注册的驱动程序在 /dev下建立相应的设备文件，同时，出于兼容性考虑，一个守护进程devfsd将会在某个设定的目录中建立以主设备号为索引的设备文件，否则，以前的一些程序将无法运行。

   使用Devfs的一个好处是，所有需要的设备节点都将由内核自动创建。内核程序在设备初始化时在/dev目录下创建相应的设备文件，在设备卸载时将它删除。这意味着/dev目录下的每一个文件都对应着一个真正存在的物理设备。设备驱动程序可以指定它的设备号、所有者以及权限，在用户空间可以修改设备的所有者和权限。

   Devfs为设备管理提供了一个简洁而又轻便的解决方案，但它仍旧具有一些不可避免的缺陷：

1. 不确定的设备映射。同一个物理设备可能会被映射成不同的设备文件，比如某个可移动存储器可能会由于插入时间的不同而被映射为sda或sdb。这无疑将会给上层应用带来麻烦。

2. 主/辅设备号不足。在Devfs中，每一个设备文件都是由两个8位数字加上设备类型来唯一标识的。这两个数字中，一个是主设备号，另外一个是辅设备号。遗憾的是，有些时候，特别是对于一些需要同时装载许多硬件设备的工作站来说，这些数字并不足够。

3. 设备命名不够灵活。在Devfs下系统管理员难以方便地修改设备文件的名字，缺省的Devfs命名机制也十分复杂，需要修改大量的配置文件和程序。

4. 不得不占用额外的内核内存。作为内核态的驱动程序，Devfs不得不消耗大量的内核内存，特别当系统的设备量很多时，带来的影响就更加严重。

2. Sysfs和Udev

    在linux2.6内核以后，一个新的文件系统sysfs被引入，以解决上述问题。跟devfs一样，它也是一个虚拟文件系统，用以管理系统设备。不同的是，它挂载于/sys下，把系统设备和总线组织成一个分级的文件系统，以供用户空间的程序利用这些信息与内核交互。这个系统信息是通过kobject子系统来建立的，是当前系统上实际设备树的直观反应。当一个kobject被创建时，对应的文件和目录也被创建了。他们位于/sys下，供用户空间读写。而udev工具就是一个用户空间的设备管理器，用以实现devfs的所有功能。

  Udev以守护进程的方式运行于Linux系统中，并监听设备初始化或卸载时内核发出的uevent。Udev能够根据系统中硬件设备的状态实时地更新，包括创建、删除设备文件，因此保证了在/dev下的设备都是系统中真实存在的，Udev为灵活的设备命名提供了解决方案。

在udev中，一个系统设备文件的创建和命名依赖于两种信息：一是sysfs提供的系统信息，二是用户提供的规则信息。这些用户自定义规则放置于/etc/udev/rules.d文件夹中，并以.rules结尾。这些规则文件为系统设备指定了不同于缺省值的命名规则，同时还包含了所有者以及用户权限等设备信息。

 Udev设备文件具有以下优点：

1.  完全在用户态工作，不会影响到内核行为。

2.  动态更新设备文件，保证/dev目录下的设备都是真正存在的。

3.  灵活的命名系统，用户可以通过简单地操作规则文件来为系统设备定制命名规则。