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