udev实际解决了哪些问题？
为此，一堆静态文件到底有什么问题/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和/或普通的旧文件是如何解决不了的呢？是否有一个特殊的原因会使许多不同的事物（热插拔，常规设备管理，网络设备管理，设备命名，驱动程序优先级等）全部成为一个程序？