Linux下有专门的文件系统用来对设备进行管理，devfs和sysfs就是其中的两种。在2.6内核之前使用的是devfs，而devfs挂载于/dev目录下，提供了一种类似于文件的方法来管理位于/dev目录下的所有设备，我们知道/dev目录下的每一个文件对应的都是一个设备，而且这些特殊文件是位于根文件系统上的，在制作文件系统的时候我们就已经建立了这些设备文件，因此通过操作这些特殊文件，可以实现与内核进行交互。
但是devfs文件系统有一些缺点：(1)比如不确定的设备映射，有时候一个设备映射的设备文件可能不同，比如我们的U盘可能对应sda也可能对应sdb。(2)比如没有足够的主/辅设备号，当设备过多的时候，这会成为一个问题。(3)/dev目录下文件太多而且不能表示当前系统上的实际设备。(4)命名不够灵活，不能任意指定。
在Linux2.6之后，引入了新的文件系统sysfs，它挂载于/sys目录下，跟devfs一样，它也是一个虚拟文件系统，也是用来对系统的设备进行管理的，它把实际链接到系统上的设备和总线组织成一个分级的文件，用户空间的程序同样可以利用这些信息以实现和内核的交互，该文件系统是当前系统上实际设备树的一个直观反应，他是通过kobject子系统来建立这个信息的，当一个kobject被创建的时候，对应的文件和目录卡也就被建立了，位于/sys下的相关目录，既然每个设备在sysfs中都有唯一对应的目录，那么也就可以被用户空间读写了。
用户空间的工具udev就是利用了sysfs提供的信息来实现所有devfs的功能的，但是不同的是udev是运行在用户空间的，而devfs是运行在内核空间，而且udev不存在devfs那些先天的缺陷。因此，sysfs是未来的发展方向。
udev是一个工具，他能够根据系统中的硬件设备的状况更新设备文件，包括设备文件的创建、删除等等。设备文件通常放置在/dev目录下，使用udev后，在/dev下面只包含系统中真实存在的设备。它是和硬件平台无关的，位于用户空间，需要内核sysfs和tmpfs的支持，sysfs位udev提供设备入口和uevent通道，而tmpfs为udev设备文件提供存放空间。
udev完全在用户态工作，利用设备加入或者移除时内核所发送的hotplug事件来工作。关于设备的详细信息是由内核输出到位于/sys的sysfs文件系统的。所有的设备命名策略、权限控制和事件处理都是在用户态下完成的。但是devfs则是位于内核的一部分工作的。
udev是用来管理/dev的，不是用来加载内核驱动的，因此udev不会在不存在的节点被打开的时候自动加载驱动。系统中所有的设备都应该产生hotplug事件、加载适当的驱动，而udev将会注意到这一点并且为它创建对应的设备节点，如果你我们不想让所有的设备驱动停留在内存当中，我们应该使用其他的东西来管理我们的模块，它不是udev的工作。devfs使用的方法曾经导致了大量无用的modprobe尝试，以此程序探测设备是否存在。每个试探性检测都会新建一个运行modprobe的进程，而几乎所有这些都是无用的。
devfs的命名是不被建议而且不被官方支持的，因为它所使用的简单枚举设备的方式在设备可能被随时加入或者删除的时候确实是一个比较笨的方法。而且这些编号带给我们的只有麻烦，而且它们并不能用来确定设备。
当内核检测到在系统中出现了新设备之后，内核会在sysfs文件系统中为该设备生成一项新的记录，一般sysfs文件系统会被mount到/sys目录中。新纪录是以一个或者多个文件或者目录的方式来表示，每个文件都包含有特定的信息。udev在系统中是以守护进程的方式udevd在运行，它通过某种途径检测到新设备的出现，通过查找设备对应的sysfs中的记录得到设备的一些信息。udev会根据/etc/udev/udev.conf文件中的udev_rules指定的目录，逐个检查该目录下的文件，这个目录的文件都是针对某类或者某个设备应该施行什么措施的规则文件。udev读取文件是按照文件名的ASCII字母顺序来读取的，如果udev一旦找到了与新加入的设备匹配的规则，udev就会根据规则定义的措施对新设备进行配置。同时不再读后续的规则文件。
至于udev不管设备连接的顺序而维持一个统一的设备名，udev通过对内核产生的设备名增加别名的方式来达到上述目的的。udev是用户模式程序，不会更改内核的行为。因此，内核依然可以产生设备名比如sda、sdb等等。但是udev可以根据设备的其他信息，比如总线信息也就是bus、生产商也就是vendor等不同来区分不同的设备，并且产生设备文件。udev只要为这个设备文件取一个固定的文件名就可以解决这个问题。在后续对设备的操作中，只要引用新的设备名就可以了。但是为了保证最大限度的兼容，一般涞水，新设备总是作为一个对内核自动产生的设备名的符号链接来使用的。
原文地址：http://blog.csdn.net/xinguimeng/article/details/44937715
