是否有使用 `udev` 的替代方法?

hum*_*ace 17 linux udev devices

虽然我理解 udev 的伟大并感谢开发人员的努力,但我只是想知道是否有替代方案。

例如,我可能会想象应该有一种方法来制作启动脚本,该脚本创建我的系统(不更改硬件)上的大多数设备节点无论如何都是相同的。

我想跳过的好处或原因与跳过udev相同dbus,即降低复杂性并通过增加我的更改来更安全地设置系统。

use*_*686 26

现代 Linux 内核支持devtmpfs文件系统(不要与古代混淆devfs,一旦内核发现它们,它就会动态地创建所有设备节点。(事实上​​,最新udev版本要求这样做;您会发现 udev 不再创建任何设备节点,只创建符号链接。)

类似地,固件加载也已移入内核,因此唯一剩下的任务udev是模块加载(根据 modaliases)和应用设备权限和其他 udev 规则。

所以理论上,一个完整的内核应该可以在没有 udev 的情况下正常启动

然而,这里真正的问题是以后会发生什么。

  1. 相当多的用户空间程序依赖 udev 维护其设备数据库,可通过libudev. 虽然枚举设备和监听添加/删除的事件可以直接使用内核接口(sysfs 和 netlink)完成,但您仍然没有各种 udev 规则附加的所有元数据。

  2. udev规则也维持在各种“执着”的符号链接/dev/disk/by-*/dev/mapper/dev/input/by-path/dev/snd/by-path,等。例如,如果您连接了两个磁盘,则不能保证第一个始终是sdasdb,但 udev 确保符号链接/dev/disk/by-uuid将继续指向正确的。

  3. 虽然设备节点现在是由内核创建的,因此不再是您关心的问题,但仍然需要注意一些设备类型已经开始使用动态分配的主/次编号,因此即使您今天拥有/dev/fuse10,228 和/dev/hpet10,229,它们也会每次重新启动后有不同的号码,这样无论是devtmpfs或(在旧系统),侦听热插拔事件是一个程序需要

其中许多事情可以通过其他程序轻松完成,例如mdev,当然。我的观点是静态/etc/MAKEDEV脚本将不再起作用......


因此,基本上,当谈到启动复杂性时,udev 很可能是您不关心的问题。

  • @Graeme:[大约 2.6.32](https://lwn.net/Articles/370418/)。 (2认同)

Gra*_*eme 25

udev外面有各种各样的选择。似乎 Gentoo 可以使用名为mdev. 另一种选择是尝试使用udev的前身devfsd。最后,您始终可以使用mknod.

请注意,对于后者,无需在启动时创建所有内容,因为节点可以在磁盘上创建,而不是像其他选项一样在临时文件系统中创建。当然,当插入新硬件(例如 U 盘)时,您将失去动态创建设备文件的灵活性。我相信这个时代的标准方法是让您合理需要的每个设备文件都已经创建/dev(即很多设备文件)。

当然,让这些方法中的任何一种在现代发行版中工作的难度可能相当高。Gentoo wiki 提到了在mdev桌面环境中工作的困难(更不用说在 Gentoo 之外了)。最后一个devfsd版本是 2002 年,我不知道它是否可以与现代内核一起使用。手动创建节点可能是最可行的方法,但即使禁用udev也可能是一个挑战,尤其是在 distos 中使用systemd(udev现在是 的一部分systemd,这表明存在很强的依赖性)。

我的建议是坚持udev;)

  • @Graeme:不,它不能。这有点像通过拆除车轮来降低汽车的复杂性。如果您对使用 systemd(它做了_很多_)启动没问题,但又非常担心 udev 的复杂性(它做的越来越少),那么你真的很困惑。 (2认同)

Jde*_*eBP 14

有几种选择:

  • 只需在作为引导程序的一部分运行的脚本中包含一组适当的chmodchownln和诸如此类的命令。
  • 使用systemd-udev作为 systemd 项目一部分的即插即用管理器。
  • 使用Gentoo 的eudev,它是systemd-udevsystemd 现在已经明显不同的分支。
  • 使用Devuan'svdev,它是由 Jude Nelson 开发的即插即用管理器,它是 Devuan 的一部分。
  • 使用mdev,与另一个答案相反,这不是 Gentoo 的东西。它是内置在BusyBox 中的即插即用管理器。
  • 使用Sucklessmdev这是季米特里斯Papastamos开发的插件和播放管理。
  • 使用Laurent Bercot 的mdevd,它与 BusyBox 的配置兼容,mdev但它自己处理套接字并且不理解 LISTEN 协议。

除了第一个之外,所有这些都需要描述如何对有关设备的内核通知事件做出反应的规则集。明显地。

还有一些工具可以使用为 设计的程序/proc/sys/kernel/hotplug,例如两个mdevs,并通过侦听 netlink 套接字然后生成这些程序来调整和序列化它们:


Gin*_*agh 5

udev?最好的选择是不要使用它。通过学习如何不使用它,Linux 和 *NIX 世界将开始变得更加合乎逻辑。

最好的长期替代方案是使用静态设备(见注释)。如果您有驱动程序,Linux 内核会管理热插拔。我更不想让 udevd 运行,永远。

dbus 是另一回事。它确实会减慢您的系统速度,但是,不断变化的脚本世界喜欢它。所以,很多东西,你已经习惯了,比如 web 浏览器或带有脚本后端的应用程序,必须被修复(在没有这些东西的情况下启动或重建或转储到另一个应用程序)。

注意:如果您只是插入闪存驱动器或 DVD 设备,请使用dmesg|tail来查看要挂载的设备的名称。了解设备是字符设备还是块设备是计算机硬件领域的基本系统知识。在 Linux 中,它是开源的,请查看有关 Linux 的很多信息,而不仅仅是嵌入式. 它最适合更广泛地理解所有 *NIX 的直接逻辑(而非哲学),例如 Linux(Solaris、HPUX、AIX 等)。

Udev、dbus、gconf/dconf、systemd、gnome-shell、Gnome、Glib、mono 和 Fedora 适合那些手头有大量时间无法 RTFM 或想要自动更新的人使用比糖蜜,越野车,半途而废的Linux。(一个真正可怕的地方,在网上寻找大量类似的经历)。

系统引导然后运行 ​​udevd。但是,它声称 udev 是必要的,因为will change重新启动时设备次要编号。Udev 的存在理由似乎处处自相矛盾。无论您咨询谁,它的文件在哪里似乎总是错误的。不要相信或 freedesktop.org。

除了 udev 被称为 systemd 的恐怖所吸收之外,我不知道人们对 /etc/udev 垃圾做了什么。而且,说编写 udev 规则在某种程度上比任何事情都好是愚蠢的。gentoo 的人似乎想坚持使用它,而不必使用 systemd,所以他们将它分叉给了 eudev。

如果你想要一个快得离谱、没有令人讨厌的惊喜的系统,请使用 Linux 基础知识。

  • 这与其说是回答,不如说是咆哮…… (8认同)
  • @jasonwryan 有点是的,仍然有一些价值,因为它建议了一些方法来手动处理通常包含在 `udev` 功能中的那些任务。指出这种*替代*方法的优势在某种程度上也是可以的。 (4认同)