我覺得這個標題名稱取得有點好笑，但是在我還不認識Entity-manager之前，我心中的疑問確實是...它們怎麼長出來的？！而它們就是我在Dbus上會看到的我系統上不同的板子，或者Devices...etc. 總之各自是一個Field Replace Unit。Entity Manager從字面上的翻譯，你大概可以猜到他在管理所有的Entity。如果再更深入一點往下看，你會發現他要可以：掃描硬體、分析 FRU、管理 Inventory、動態產生物件、觸發其他 daemon以及維護一份「整台機器的配置」。
它是怎麼做到這些的？開機時，entity-manager 手上只有「設計圖」
當 BMC 剛 boot 起來，entity-manager 起身運作時，它其實對硬體一無所知。它手上只有：
- configurations/*.json (建議大家去這個目錄底下，認真的看一看...會發現很多寶物)
由平台提供，描述「我期待有哪些硬體」。像這裡的 Motherboard FRU 就是其中一筆。(這個Probe資訊在json檔案的最底下）
"Name": "Yosemite5 MB",
"Probe": "xyz.openbmc_project.FruDevice({'PRODUCT_PRODUCT_NAME': 'Yosemite V5 .*', 'BOARD_PRODUCT_NAME': 'Motherboard', 'BOARD_MANUFACTURER': '(Quanta|Wiwynn)'})",
"Type": "Board",
"xyz.openbmc_project.Inventory.Decorator.Asset": {
"BuildDate": "$BOARD_MANUFACTURE_DATE",
"Manufacturer": "$BOARD_MANUFACTURER",
"Model": "$BOARD_PRODUCT_NAME",
"PartNumber": "$BOARD_PART_NUMBER",
"SerialNumber": "$BOARD_SERIAL_NUMBER",
"SparePartNumber": "$BOARD_INFO_AM1"
},
"xyz.openbmc_project.Inventory.Decorator.AssetTag": {
"AssetTag": "$PRODUCT_ASSET_TAG"
}
2. /etc/phosphor-middleware/configurations（可覆蓋）
- runtime cache：/var/configuration/system.json
上一輪掃描後留下的系統快照。但這些都只是「期望」，不是真實世界。entity-manager 的任務不是盲目地把 JSON 映射到 Inventory，而是要 先去外面跑一圈，看機器上實際有哪些 D-Bus 物件存在。只有當 JSON 的 Probe 跟 D-Bus 上的實際屬性吻合時，它才會說：「喔，原來這就是我 JSON 裡那塊 Motherboard。」
Probe：設定檔與真實硬體的連結
每一筆 configuration record 裡最重要的欄位是：
"Probe": "xyz.openbmc_project.FruDevice({...})"
這一行的意義非常重大：
Probe 是「我要去哪裡找這個設備，以及我要如何判斷它是它」。
以 Motherboard FRU 為例，我們用 regex 規範：
- PRODUCT_PRODUCT_NAME：要是 Yosemite V5 開頭
- BOARD_PRODUCT_NAME：要是 Motherboard
- BOARD_MANUFACTURER：要符合 Quanta 或 Wiwynn
如果這三項都符合，就認定：「這個 D-Bus 的 FruDevice，就是 Yosemite V5 的 Motherboard。」entity-manager 不會自己發明創造出任何資訊，它全部都要從 D-Bus 的 GetAll 的 FRU 欄位拿資料。
BMC 上的 FRU 是怎麼出現在 D-Bus 上的？
看完前面那段，如果你知道product name, manufacturer ....etc是什麼？那真是萬幸！如果你並不知道，那你應該會感覺你看了一段廢話。好，總之，每個FRU (Field Replace Unit) 都會有他的一些出廠資訊，這個資訊會來說明他是誰？就像...你的身分證。這個東西會被存在板子或該硬體上的EEPROM，出廠之後理論上就不能被修改了，除非...某些原因。而上述的Probe就是OpenBMC嘗試在設定檔裡面告訴韌體，你再開機的時候要怎麼知道你系統上會有的硬體是誰？符合我在設定檔中告訴你的這些規則的就是我們在找的FRU。
回頭想想，那系統開機的時候肯定有人把FRU的資訊從硬體讀到BMC這兒～不然在做Probe的時候, 要拿什麼資訊跟設定檔的規則做比較？？
在Entity-manager底下有一個目錄叫做fru-device，fru_device 是獨立的 systemd 服務（xyz.openbmc_project.FruDevice），在 BMC 上電後及早啟動，讓 Inventory 先建立 FRU 資訊。
你先想像，程式會從 I²C、EEPROM、MCTP 或其他來源讀出 FRU raw data，然後解析成 key/value pair，最後在 D-Bus 上建立：
/xyz/openbmc_project/FruDevice/board0
/xyz/openbmc_project/FruDevice/chassis
/xyz/openbmc_project/FruDevice/nic0
/xyz/openbmc_project/FruDevice/dcscm0
…
並提供 interface：
xyz.openbmc_project.FruDevice
底下是一堆 property，例如：
- PRODUCT_PRODUCT_NAME
- BOARD_PRODUCT_NAME
（詳細的fru-device這支service，我們再找個時間細聊。）
今天就先聊到這邊啦～我們下集見！
喜歡我的OpenBMC系列文章，想鼓勵我繼續寫下去的朋朋，可以留言給我一些評論和指導，覺得不錯也可以請我喝杯咖費贊助我窩在咖啡廳寫文章的摳摳喔！甘溫 ：）
