devfs、sysfs、udev介绍

一、devfs

linux下有专门的文件系统用来对设备进行管理，devfs和sysfs就是其中两种。在2.6内核以前一直使用的是devfs，devfs挂载于/dev目录下，提供了一种类似于文件的方法来管理位于/dev目录下的所有设备，我们知道/dev目录下的每一个文件都对应的是一个设备，至于当前该设备存在与否先且不论，而且这些特殊文件是位于根文件系统上的，在制作文件系统的时候我们就已经建立了这些设备文件，因此通过操作这些特殊文件，可以实现与内核进行交互。但是devfs文件系统有一些缺点，例如：不确定的设备映射，有时一个设备映射的设备文件可能不同，例如我的U盘可能对应sda有可能对应sdb；没有足够的主/辅设备号，当设备过多的时候，显然这会成为一个问题；/dev目录下文件太多而且不能表示当前系统上的实际设备；命名不够灵活，不能任意指定等等。

 

二、sysfs

正因为上述这些问题的存在，在linux2.6内核以后，引入了一个新的文件系统sysfs，它挂载于/sys目录下，跟devfs一样它也是一个虚拟文件系统，也是用来对系统的设备进行管理的，它把实际连接到系统上的设备和总线组织成一个分级的文件，用户空间的程序同样可以利用这些信息以实现和内核的交互，该文件系统是当前系统上实际设备树的一个直观反应，它是通过kobject子系统来建立这个信息的，当一个kobject被创建的时候，对应的文件和目录也就被创建了，位于/sys下的相关目录下，既然每个设备在sysfs中都有唯一对应的目录，那么也就可以被用户空间读写了。用户空间的工具udev就是利用了sysfs提供的信息来实现所有devfs的功能的，但不同的是udev运行在用户空间中，而devfs却运行在内核空间，而且udev不存在devfs那些先天的缺陷。很显然，sysfs将是未来发展的方向。

The top level sysfs directory looks like:
block/
bus/
class/
devices/
firmware/
net/
fs/

devices/  contains a filesystem representation of the device tree. It maps directly to the internal kernel device tree, which is a hierarchy of struct device.
bus/ contains flat directory layout of the various bus types in the kernel. Each bus's directory contains two subdirectories:
devices/
drivers/
devices/ contains symlinks for each device discovered in the system that point to the device's directory under root/.

drivers/ contains a directory for each device driver that is loaded for devices on that particular bus (this assumes that drivers do not span multiple bus types).

fs/ contains a directory for some filesystems. Currently each filesystem wanting to export attributes must create its own hierarchy below fs/ (see ./fuse.txt for an example).

三、udev
    udev是一种工具，它能够根据系统中的硬件设备的状况动态更新设备文件，包括设备文件的创建，删除等。设备文件通常放在/dev目录下，使用udev后,在/dev下面只包含系统中真实存在的设备。它于硬件平台无关的，位于用户空间，需要内核sysfs和tmpfs的支持，sysfs为udev提供设备入口和uevent通道，tmpfs为udev设备文件提供存放空间。

 

 

 

本文档遵循 GPL 2 及以后版本发布，修改、发布请保持许可证不变

问: udev是什么? 它的目的何在?
答: 看看那篇 OLS 2003 上的有关 udev 的文章吧，可以在 docs 目录里找到，也能在这里找到:

 

问: udev 和 devfs 是什么关系
答: udev 完全在用户态 (userspace) 工作，利用设备加入或移除时内核所发送的hotplug 事件 (event) 来工作。关于设备的详细信息是由内核输出 (export) 到位于 /sys 的 sysfs 文件系统的。所有的设备命名策略、权限控制和事件处理都是在用户态下完成的。与此相反，devfs 是作为内核的一部分工作的。

问: 如果 udev 不能完成所有 devfs 的工作的话，为什么把 devfs 标记为OBSOLETE/removed?
答: 引用 Al Viro (Linux VFS 内核维护者):
- devfs 所做的工作被确信可以在用户态来完成。
- devfs 被加入内核之时，大家寄望它的质量可以迎头赶上。
- devfs 被发现了一些可修复和无法修复的 bug。
- 对于可修复的 bug，几个月前就已经被修复了，其维护者认为一切良好。
- 对于后者，同样是相当常一段时间以来没有改观了。

devfs 的维护者和作者对它感到失望并且已经停止了对代码的维护工作。

 

问: 但是当一个并不存在的 /dev 节点被打开的时候，udev 并不能如 devfs 一样自动加载驱动程序。
答: 的确如此，但 Linux 的设计是在设备被发现的时候加载模块，而不是当它被访问的时候。

问: 不过等等，我确实希望 udev 可以在不存在的节点被打开的时候自动加载驱动。这是我使用 devfs 的唯一原因了。给 udev 增加这个功能吧。
答: 不，udev 是用来管理 /dev 的，不是用来加载内核驱动的。

问: 嗨，求你们了。这不难做到的。
答: 这么个功能对于一个配置正确的计算机是多余的。系统中所有的设备都应该产生hotplug 事件、加载恰当的驱动，而 udev 将会注意到这点并且为它创建对应的设备节点。如果你不想让所有的设备驱动停留在内存之中，应该使用其它东西来管理你的模块 (如脚本, modules.conf, 等等) 这不是 udev 的工作。

问: 但是我真的喜欢那个功能，还是加上吧
答: devfs 用的方法导致了大量无用的 modprobe 尝试，以此程序探测设备是否存在。每个试探性探测都新建一个运行 modprobe 的进程，而几乎所有这些都是无用的。

问: 我喜欢 devfs 的设备文件命名方式，udev 可以这样命名么?
答: 可以，udev 可以使用 /dev 的命名策略来创建节点。通过一个配置文件，可以把内核缺省的名字映射到 devfs的名字。可以看看 udev 中带的 udev.rules.devfs 文件。
注意: devfs 的命名方式是不被建议并且不被官方支持的，因为它所用的简单枚举设备的方式在设备可能被随时加入或删除的情况下确实是一个比较笨的方法。这些编号代给你的将只有麻烦，而并不能用来确定设备。看看那个永久性磁盘 (persistentdisk) 的规则就知道如何在用户态下正确的做这件事，而不是傻傻地列出设备。

问: udev 可以为哪些设备创建节点?
答: 所有在 sysfs 中显示的设备都可以由 udev 来创建节点。如果内核中增加了其它设备的支持，udev 也就自动地可以为它们工作了。现在所有的块设备都在被支持之列，大部分的主字符设备也是被支持的。内核开发者们正致力于让所有的字符设备都被支持。可以到 linux-kernel 邮件列表上寻找补丁或是查看补丁的状态。

问: udev 是否会去掉匿名设备数量的限制?
答: udev 完全工作于用户态。如果内核支持了更多的匿名设备，udev 就会支持。

问: udev 是否会支持符号链接?
答: udev 现在就支持符号链接，每个设备节点拥有多个符号链接也是被支持的。

问: udev 如何处理 /dev 文件系统?
答: 建议使用一个每次启动系统的时候重新创建的 tmpfs 作为 /dev 的文件系统。不过实际上 udev 并不关心那种文件系统在被使用。

问: 在 init 运行之前，udev 如何处理设备?
答: udev 可以被放入 initramfs 之中，并在每个设备被发现的时候运行。也可以让udev 工作在一个真的根分区被加载之后根据 /sys 的内容创建的初始 /dev 目录之中。

问: 我是否可以利用 udev 在一个 USB 设备被加载的时候自动加载上这个设备?
答: 技术上讲是可以的，但是 udev 不是用于这个工作的。所有的主流发布版 (distro)都包含了 HAL ( 用于这个工作，它也是专门用于监视设备变更的，并且集成进入了桌面软件。换个角度说，这可以简单的通过 fstab 来实现:
/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0

这样，用户可以用如下命令来访问设备:
$mount /media/PENDRIVE
同样不需要管理员权限，但却拥有了设备的全部访问权限。使用永久性磁盘链接 (label, uuid) 将可以指定同一设备，无论其实际上的内核名字是什么。

问: 有什么我需要注意的安全问题么?
答: 当使用动态设备编号的时候，一个给定的主/从设备号可能在不同时间对应不同的设备，如果一个用户拥有对这个节点的访问权限，并且可以创建一个到这个节点的硬链接，他就可以如此得到一个这个设备节点的拷贝。当设备被移除之后，udev 删除了设备节点，但硬链接依然存在。如果这个设备节点之后被重新使用不同的访问权限被创建的时候，其硬链接仍然可以使用先前的访问权限来访问。 (同样的问题也存在在使用 PAM 改变访问权限的login 上。)

简单的解决方案就是通过把 /dev 放在 tmpfs 这样的单独的文件系统之上来防止建立硬链接。

问: 我有其他的关于 udev 的问题，我应该问谁?
答: linux-hotplug-devel 正是问这些的地方。邮件列表的地址是
[e-mail]
加入邮件列表的相关信息可以在如下地址找到
<https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel>
邮件列表的上的既往讨论记录可以在下面地址找到
<http://marc.theaimsgroup.com/?l=linux-hotplug-devel

 

 

理解和认识udev

http://www.cublog.cn/opera/showart.php?blogid=6006&id=65174                
                
    因为本身从事存储行业，在工作中多次碰到用户有这样的要求：我的linux系统中原来有一块SCSI硬盘，系统分配的设备文件是/dev/sda。现在新增加了一个外置的磁盘阵列，通过SCSI卡连接。但接上这个磁盘阵列后，/dev/sda变成了磁盘阵列的硬盘了，原来内置的SCSI硬盘变成了/dev/sdb，我希望将设备文件固定下来。
    过去，我总是对用户说，这个比较麻烦，因为/dev/sda等文件都是linux内核自动分配的。很难固定下来，除非你更改加载SCSI卡驱动程序的顺序，让内置硬盘连接的SCSI卡比外接磁盘阵列连接的SCSI卡的驱动模块先加载到内核，这样就能保证/dev/sda总是指向内置的硬盘。但这种解决方法毕竟不太完美，而且对于其他的即插即用设备，如USB设备等都不适用。
    近来，通过安装和升级linux-2.6内核，发现这个问题已经可以通过2.6内核新的sysfs文件系统和udev程序得到解决。下面就是我在学习了udev配置后的一点心得。我喜欢用FAQ的形式来说明。

问：什么是udev?
答：udev是一种工具，它能够根据系统中的硬件设备的状态动态更新设备文件，包括设备文件的创建，删除等。设备文件通常放在/dev目录下。使用udev后，在/dev目录下就只包含系统中真正存在的设备。

问：udev支持什么内核？
答：udev只支持linux-2.6内核，因为udev严重依赖于sysfs文件系统提供的信息，而sysfs文件系统只在linux-2.6内核中才有。

问：udev是一个内核程序还是用户程序？
答：udev是一个用户程序（user-mode daemon）。

问：udev和devfs有什么差别？
答：udev能够实现所有devfs实现的功能。但udev运行在用户模式中，而devfs运行在内核中。据称：devfs具有一些不太容易解决的先天缺陷。

问：udev的配置文件放在哪里？
答：udev是一个用户模式程序。它的配置文件是/etc/udev/udev.conf。这个文件一般缺省有这样几项：
udev_root="/dev" ; udev产生的设备文件的根目录是/devudev_db="/dev/.udevdb" ; 通过udev产生的设备文件形成的数据库udev_rules="/etc/udev/rules.d" ;用于指导udev工作的规则所在目录。

udev_log="err" ;当出现错误时，用syslog记录错误信息。

问：udev的工作过程是怎样的？
答：由于没有研究过udev的源程序，不敢贸然就说udev的工作过程。我只是通过一些网上的资料和udev的说明文档，大致猜测它的工作过程可能是这样的。
  当内核检测到在系统中出现了新设备后，内核会在sysfs文件系统中为该新设备生成一项新的记录，一般sysfs文件系统会被mount到/sys目录中。新记录是以一个或多个文件或目录的方式来表示。每个文件都包含有特定的信息。（信息是如何表述的，还要另外研究？）
  udev在系统中是以守护进程的方式udevd在运行，它通过某种途径（到底什么途径，目前还没搞懂。）检测到新设备的出现，通过查找设备对应的sysfs中的记录得到设备的一些信息。
  udev会根据/etc/udev/udev.conf文件中的udev_rules指定的目录，逐个检查该目录下的文件，这个目录下的文件都是针对某类或某个设备应该施行什么措施的规则文件。udev读取文件是按照文件名的ASCII字母顺序来读取的，如果udev一旦找到了与新加入的设备匹配的规则，udev就会根据规则定义的措施对新设备进行配置。同时不再读后续的规则文件。

问：udev的规则文件的语法是怎样的？
答：udev的规则文件以行为单位，以"#"开头的行代表注释行。其余的每一行代表一个规则。每个规则分成一个或多个“匹配”和“赋值”部分。“匹配”部分用“匹配“专用的关键字来表示，相应的“赋值”部分用“赋值”专用的关键字来表示。“匹配”关键字包括：ACTION，KERNEL，BUS，SYSFS等等，“赋值”关键字包括：NAME，SYMLINK，OWNER等等。具体详细的描述可以阅读udev的man文档。

    下面举个例子来说明一下，有这样一条规则：SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0d:87:f6:59:f3", IMPORT="/sbin/rename_netiface %k eth0"
    这个规则中的“匹配”部分有三项，分别是SUBSYSTEM，ACTION和SYSFS。而"赋值"部分有一项，是IMPORT。这个规则就是说，当系统中出现的新硬件属于net子系统范畴，系统对该硬件采取的动作是加入这个硬件，且这个硬件在SYSFS文件系统中的“address”信息等于“00：0d..."时，对这个硬件在udev层次施行的动作是调用外部程序/sbin/rename_netiface，传递的参数有两个，一个是“%k”，代表内核对该新设备定义的名称。另一个是”eth0“。    从上面这个例子中可以看出，udev的规则的写法比较灵活的，尤其在“匹配”部分中，可以通过诸如”*“, ”?“,[a-c],[1-9]等shell通配符来灵活匹配多个匹配项。具体的语法可以参考udev的man文档。

问：udev怎样做到不管设备连接的顺序而维持一个统一的设备名？
答：实际上，udev是通过对内核产生的设备名增加别名的方式来达到上述目的的。前面说过，udev是用户模式程序，不会更改内核的行为。因此，内核依然会我行我素地产生设备名如sda,sdb等。但是，udev可以根据设备的其他信息如总线（bus），生产商（vendor）等不同来区分不同的设备，并产生设备文件。udev只要为这个设备文件取一个固定的文件名就可以解决这个问题。在后续对设备的操作中，只要引用新的设备名就可以了。但为了保证最大限度的兼容，一般来说，新设备名总是作为一个对内核自动产生的设备名的符号链接（link）来使用的。

 例如：内核产生了sda设备名，而根据信息，这个设备对应于是我的内置硬盘，那我就可以制定udev规则，让udev除了产生/dev/sda设备文件外，另外创建一个符号链接叫/dev/internalHD。这样，我在fstab文件中，就可以用/dev/internalHD来代替原来的/dev/sda了。下次，由于某些原因，这个硬盘在内核中变成了sdb设备名了，那也不用着急，udev还会自动产生/dev/internalHD这个链接，并指向正确的/dev/sdb设备。所有其他的文件像fstab等都不用修改。

问：怎样才能找到这些设备信息，并把他们放到udev的规则文件中来匹配呢？
答：这个问题比较难，网上资料不多，我只找到一篇文章来介绍如何写udev的规则。他的基本方法是通过udevinfo这个实用程序来找到那些可以作为规则文件里的匹配项的项目。有这样两种情况可以使用这个工具：
    第一种情况是，当你把设备插入系统后，系统为设备产生了设备名（如/dev/sda）。那样的
话，你先用udevinfo -q path -n/dev/sda，命令会产生一个该设备名对应的在sysfs下的路径，如/block/sda。然后，你再用udevinfo -a -p/sys/block/sda，这个命令会显示一堆信息，信息分成很多块。这些信息实际来自于操作系统维护的sysfs链表，不同的块对应不同的路径。你就可以用这些信息来作为udev规则文件中的匹配项。但需要注意的是，同一个规则只能使用同一块中显示的信息，不能跨块书写规则。
    第二种情况是，不知道系统产生的设备名，那就只有到/sys目录下去逐个目录查找了，反复用udevinfo
-a -p/sys/path...这个命令看信息，如果对应的信息是这个设备的，那就恭喜你。否则就再换个目录。当然，在这种情况下，成功的可能性比较小。

============================================================================================

http://blog.csdn.net/aaronychen/article/details/2953345

原文地址：