为此，一堆静态文件到底有什么问题/dev？对于开发人员来说，按我的观点重新发明这个轮子显然不够令人满意（devfs-> udev + HAL-> udev），现在看来，它也已经进入了Grand Unified Init计划了四次。

我记得几年前刚开始使用Linux时感到惊讶的是，尽管声称“一切都是文件”，但是没有/dev/eth0（后来才有意义，因为它不是char或block设备-尽管是“ packet”设备类型会很有趣...）。既然如此，为什么处理char和block设备文件树的程序也负责网络设备？我看到过模糊的对“灵活性”的引用，但是如果仅仅看一下，这会增加ifconfig（8）的作用/proc/net/dev？我知道，例如NetworkManager不会很快出现在Net或OpenBSD中，因为它依赖于udev，两个团队都不愿编写。我不/dev内核已经以多种方式公开了这些代码（并且在/dev！中都没有）。

仅仅是因为热插拔吗？内核仅侦听物理总线并在“添加设备”消息上加载适当的模块是否存在问题？或者，上帝禁止，实际的管理员这样做吗？我确实记得在2000年代初期，我的服务器有时会以意想不到的顺序初始化其网卡，并且我认为在用户名中确定命名是很有意义的（尽管那时并不难解决），但是这似乎是蟑螂的大锤。（或者这个问题对用例而言，我没有想过比机架式服务器或PC难得多，这是我的经验。）

因此，要明确地说出我的问题：udev实际解决了哪些问题，而devfs，HAL和/或普通的旧文件是如何解决不了的呢？是否有一个特殊的原因会使许多不同的事物（热插拔，常规设备管理，网络设备管理，设备命名，驱动程序优先级等）全部成为一个程序？

还有两件事：Linux进入企业级和其他大型服务器的过程暴露了静态/dev漏洞。在消费者和企业中，先进的技术都将静态/ dev当作笑话。[这个答案填补了更多的背景知识，特别是为什么devfs被udev取代的原因]。

主要和次要数字空间的耗尽

/dev文件在内核中通过主次编号来标识。内核从未真正关心过这个名称（例如，您可以，mv /dev/sda /dev/disk-1而且它会继续工作，尽管程序当然不知道在哪里可以找到它）。

使用static时/dev，您需要为可能存在的每个潜在设备分配一个主要/次要编号。这些数字在全球范围内必须是唯一的，因为它们是发行版的一部分，而不是按需提供的。问题在于它们都是8位数字，范围是0-255。

例如，最初，Linux的开始是8,0是sda，8,1是sda1，8,16是sdb，等等。但是人们一直在向计算机添加越来越多的磁盘，尤其是在考虑诸如光纤通道之类的东西时。因此，在某些时候，主要数字65-71被添加以用于更多磁盘。后来，主要数字为128–135。但是人们一直想要更多的磁盘...

诸如GPT之类的分区表格式应运而生，每个磁盘支持更多分区。当然，其他设备正在吞噬数字空间：各种RAID控制器，逻辑卷管理等。

最终结果可以在LANANA Linux设备列表中看到。如果查看2.6列表（仍然是唯一的列表），则会使用很多块主数字，直到200（最大：255）。显然，这些数字已经用完了。

更改为更大的数字并不容易。它更改了内核ABI。根据文件系统，它会更改磁盘布局。但是，当然，其中大多数设备都不存在于任何一个系统上，即使是（例如）用完SCSI磁盘的设备也可能有很多空闲的东西–它可能不需要IBM XT硬盘，例如。

使用dynamic /dev，发行版不必附带设备编号。它们不再必须是全球唯一的。它们甚至不必在靴子上唯一。

设备名称不可预测

以前，给所有内容分配一个数字非常容易。一块板上有两个IDE通道。每个IDE通道都支持一个主机和一个从机。您可以按通道顺序分配，也可以先按主从分配。因此hda成为第一频道，大师；hdb第一频道，奴隶；hdc第二频道，主人；等。这些是可预测的和稳定的。如果添加新驱动器或卸下一个驱动器，它们可能会更改，但是如果没有硬件更改，它们是静态的。

你可以把/dev/hda1你/etc/fstab并相信它会留下来工作，至少不存在硬件更改。

IDE就是这样工作的。没事做。

SATA看起来很简单：一个端口，一个磁盘。但事实并非如此；它允许端口倍增器。而且它允许热插拔。尽管如此，在没有硬件更改的情况下，您实际上仍可以保持映射正常运行。

USB要糟糕得多。它不仅允许热插拔，而且很典型。人们一直在插入USB闪存驱动器。此外，设备可能需要花费一些时间进行探测，并且实际上可以随时随地更改（例如，在手机上打开或关闭USB存储模式时）。火线是相似的。两者都不能真正提供稳定的映射。

网络连接的磁盘没有任何固有的端口顺序。内核使用的唯一顺序是它们出现的顺序。与逻辑卷相同。

对启动速度的追求也使情况变得更糟。最初，内核会很乐意坐下来，等待相当长的时间，例如，所有USB设备都要初始化。为了全面探测所有SCSI总线等。引导将不再等待它们。探针完成后，将添加设备。

因此内核或多或少地具有“它们以什么顺序出现”的信息。这意味着许多类型的设备可以而且确实在每次引导时都会更改顺序-一个引导上的内容是/dev/sdb另一个引导上的内容/dev/sdc。这使静态的想法成为/dev一个笑话。

摘要

当您/dev由于无法预测的设备探测顺序而将静态的组合变得越来越无意义，并继续分配静态的主要/次要数字而导致大量工作没有用完时，很明显，Linux的开发人员为何选择切换到动态/dev。

好问题。

从某种意义上说，可以解决这个问题：由于内核2.6.13引入了的新版本uevent，因此一定会发生这种情况，devfs需要利用接口的新功能进行重写。因此，从某种意义上讲，问题应该是为什么要更改内核。

但是，从表面上看，您的问题将在此Wikipedia的文章中得到解答：

与传统的Unix系统不同，在传统的Unix系统中，/ dev目录中的设备节点是一组静态文件，Linux udev设备管理器动态地仅为系统中实际存在的设备提供节点。尽管devf曾经提供过类似的功能，但Greg Kroah-Hartman列举了一些比devfs更喜欢实现的原因：

1）udev支持持久性设备命名，例如，这不依赖于设备插入系统的顺序。默认的udev设置为存储设备提供永久名称。任何硬盘都可以通过其唯一的文件系统ID，磁盘名称以及所连接的硬件上的物理位置来识别。

2）udev完全在用户空间执行，而不是devfs的内核空间。结果是udev将命名策略移出了内核，并且可以在创建节点之前运行任意程序来根据设备的属性为设备命名。在那里，整个过程也是可中断的，并且以较低的优先级运行。

我可能应该补充一点，使用udev race condition可以避免使用，它基本上破坏了devfs和hotplug中设备的命名。换句话说：使用devfs时，无法确保将调用最左边的以太网端口eth0及其最右边的以太网端口eth1，这（纯粹的例子）使设置路由器（到WAN的一个端口，到LAN的一个端口）的设置变得困难。实行。

采用基于GUID的磁盘命名方案是另外一个优势，并将整个过程移到用户空间更大的过程：您是否已搜索过该站点以查看有多少人编写了自己的udev规则？

作为在用户空间中使用udev的固有优势的简单示例，请在此站点上同时检查此问题或其他问题。