我很困惑 hal 是否真的在用或者仅仅是 udev。
我的理解是:
一般来说,HAL 是一个允许操作系统与硬件设备交互的抽象层。
守护进程 hald 与 HAL 不同。它是一种提供 HAL 的服务,用于识别设备,然后挂载它们(以及它们所在的位置,在 /dev 下?)或自动配置它们以供应用程序使用。
现在它已被 udev 弃用,它也做类似的事情,即通过读取内核的消息并根据预定义的规则命名来自动安装所连接的设备。
目前只有少数基于 GUI 的应用程序(例如 GNOMe)使用 hald 来获取有关新连接设备的通知(而挂载仍由 udev 负责?)
所以我的问题是,hal 是否仅用于通知基于 GUI 的应用程序有关新连接的硬件,因为它可以通过 DBUS 进行通信,但 udev 没有 dbus 实现。对于自动安装设备,只有 udev 可以做到这一点,而 hal 在哪里用不到?
我特别谈论的是 Redhat 5、6 和 7。
谢谢。
答案1
一些背景知识:udev
已经存在很久了(自 2.5 内核以来)并且(对于 RHEL)它是在驱动程序宣布宣布硬件时设置设备节点的东西。即使在使用 HAL 的系统上,udev
底层仍然存在。udev
当它“发现”变化时,它本身可以调用其他程序,而 HAL 试图抽象出桌面 *nix 系统(不仅是 Linux,还有其他系统,如 FreeBSD)某些新硬件的公告和配置。最终,人们废除了 HAL 的某些部分,但并非所有 HAL 部分都可以移动udev
- 其中一些被拆分成其他守护进程。到 2012 年左右,大多数尖端 Linux 发行版都放弃了 HAL,而如今(2019 年初),上述守护进程是诸如 等udisks
。upower
在 上有一个很好的总结https://en.wikipedia.org/wiki/HAL_(软件)...
因此,鉴于 RHEL 大致基于 Fedora(粗略映射可以在https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Relationship_with_Fedora)并且我们知道这是不含 HAL 的 Fedora 16:
- RHEL 5 肯定会有
hald
- RHEL 6 可能会有
hald
- RHEL 7 没有
hald
并且其他守护进程将接管udev
无法说服去做的事情。
如何查明 RHEL 服务器中是否正在使用 haldaemon 或 udev?
只需启动适当版本的 RHEL 并执行以下操作:
rpm -qa "*hal*"
(哦,不,我刚刚意识到你在同一个问题中隐藏了多个问题 :-( )
守护进程 hald 与 HAL 不同。它是一种提供 HAL 的服务,用于识别设备,然后挂载它们(以及它们所在的位置,在 /dev 下?)或自动配置它们以供应用程序使用。
设备位于下方/dev
,但我是否需要“安装”设备则取决于具体情况。我可能会安装磁盘(例如,位于下方,/mnt
但也有其他地方可以安装),但我不会安装扫描仪(宣布/查找扫描仪是 HAL 处理的事情)。
现在它已被 udev 弃用,它也做类似的事情,即通过读取内核的消息并根据预定义的规则命名来自动安装所连接的设备。
有时它仅由完成udev
,有时其他服务也会参与。/dev
设备命名是在udev
控制之下,是的。
目前只有少数基于 GUI 的应用程序(例如 GNOM[E])使用 hald 来获取有关新连接设备的通知(而挂载仍由 udev 负责?)
嗯,现代系统没有,hald
所以你的问题很奇怪也很复杂。此外,即使在有的系统上,答案也是“视情况而定”。是的,udev
可以进行安装,但有时诸如通过 PTP 协议连接 USB 摄像头之类的事情几乎由 GNOME 用户空间处理(尽管我猜你可以争论整个 FUSE 角度)。
所以我的问题是,hal 是否仅用于通知基于 GUI 的应用程序有关新连接的硬件,因为它可以通过 DBUS 进行通信,但 udev 没有 dbus 实现。
这是个问题吗?HAL 用于通知 GUI 应用程序,但它也可以在设备发生变化时触发其他操作(例如调整电源规则/安装磁盘)。
对于自动安装设备,只有 udev 可以做到这一点,而没有使用 hal?
再次强调,这是双方共同努力的结果。是的,udev
规则可以做很多事情,但根据具体情况,可能还会涉及其他事情(例如,如果您需要开始提示用户),这就是udisks
开始参与其中的地方。
我猜这里有一个潜台词:你为什么要问是否使用了 HAL?你最好直接问这个问题...
(这些由多个部分组成的问题很痛苦 :-( )