介紹 Entity Manager 的設計理念、設定語法與運作機制。以下是這篇內容的核心重點摘要:
開發動機與核心目標:過去將 OpenBMC 移植到新硬體平台需要耗費一週甚至一個月的時間,且充滿各種硬編碼 (Hardcodes)。Entity Manager 的目標是提供一個集中式的設定系統,並支援單一系統映像檔 (Monolithic image) 適用於同世代的多種硬體平台,大幅減少平台移植的工作量。彈性的探測機制 (Probing):Entity Manager 本身並不直接掃描底層硬體,這兩者有明確的界線。它主要是透過監聽 D-Bus 上的特定介面與鍵值對(最常見的是 FruDevice 探測到的 FRU 資訊)來判斷硬體是否存在。只要條件符合,它就會將對應的 JSON 設定資料發佈到 D-Bus 上,觸發其他應用程式(如感測器或 PID 散熱控制)進行重新設定。動態載入與系統配置:有別於在編譯時期將裝置寫死在 Device Tree,Entity Manager 允許在系統執行期間 (Runtime) 動態安裝裝置並匯出至 sysfs。它還能為 I2C 多工器 (Muxes) 建立對應的符號連結 (Symlinks),解決系統開機時 I2C 匯流排編號不可預測的問題。強大的 JSON 設定檔語法:樣板語法 (Template syntax):能自動抓取底層探測到的資訊(例如製造商名稱或產品名稱)來動態填寫設定檔內容,減少重複撰寫。數學運算與固定編號:支援基礎數學運算(如利用 I2C 網址取餘數),確保無論硬體安裝在哪個插槽,元件(如電源供應器 PSU)都能維持固定的邏輯編號(例如永遠固定為 PSU 1 與 PSU 2)。條件式覆寫:支援 removes 或 disable node 等語法。可以根據不同的基板或機殼類型(例如開放式或封閉式機殼),動態移除或覆寫原本的風扇散熱設定。高度的模組化與重用性:Intel 團隊刻意將設定檔依照個別硬體元件(如單一型號的電源供應器、前置面板或擴充卡)拆分成獨立檔案。當未來的新系統使用相同的元件時,系統會自動支援,開發者通常只需撰寫新基板的設定檔即可。執行期更新與 Redfish 整合:Entity Manager 支援在系統運作時新增或移除硬體的動態更新,並且與 Redfish 及 BMCWeb 有完整的整合。散熱團隊甚至能直接在系統執行期間,透過 Redfish 修改風扇或 PID 控制的閾值,這些變更會被永久儲存於 system.json 檔案中。未來發展:開發團隊計畫未來會導入更嚴格的 JSON 結構驗證 (Schema validation) 以防設定檔寫錯,並考慮與 U-Boot DTS 進行更深度的整合,以支援更複雜的 I2C 拓撲架構。
--
Hosting provided by SoundOn