我很困惑 hal 是真的在使用還是只是 udev 。
我的理解是：
一般來說，HAL 是一個抽象層，允許作業系統與硬體設備互動。
而且daemon 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*"
（哦不，我剛剛意識到你在一個問題中隱藏了多個問題:-( )
而且daemon 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？你直接問這個問題可能會更好...
（這些由多部分組成的問題很痛苦:-( )