Ciao, 寫給還在韌體底層摸黑仍然沒有放棄的你們 ☕🇮🇹
來找我諮詢的同學, 很常問我的一題是…要轉韌體工程師要有什麼技能？我想了想…程式這種東西好像也沒有再分軟韌體！可是, 寫韌體一定要會作業系統, 特別是作業系統當中某些主題。大學畢業之後很可能就把這些都還給老師了, 以至於常常在面試的時候問研究所同學記憶體管理, deadlock, race condition….etc, 我都感覺空氣瞬間凝結。試想一下, 現在在你腦中的作業系統, 還有些什麼？當然, 面試也很常遇到電子電機相關科系, 或是數學系…etc非資訊工程系所的同學, 如果你們也能懂作業系統, 那可就更加分了。話不多說, 這期就簡單來聊一點點作業系統的概念吧！
By 摸黑了這麼多年還在摸黑還沒有放棄的我 Bonnie ( •̀ᴗ•́ )و ̑̑
概念
Process（有時候中文書會寫”進程”）是作業系統中正在執行的程式, 每個Process都有獨立的記憶體空間和系統資源。fork() 這個function是系統用於創建新的subprocess, 它會複製parent process的記憶體內容, 讓subprocess可以從相同的狀態開始執行。OpenBMC 中的使用情境
phosphor-host-ipmid：處理 IPMI command時, 偶爾需要create subprocess執行特定工作bmcweb：HTTP 服務器處理某些阻塞操作時可能使用subprocesssystemd(service)：透過 systemd 管理各種service的啟動和監控
在 OpenBMC 的嵌入式環境中，建立新 process（使用 fork()）的成本相對較高，因此系統設計上多半會透過 systemd 來統一管理與啟動服務進程，而不是由應用程式動態自行 fork() 新子進程。這樣的設計背後有幾個考量：
- 資源限制：BMC 的硬體資源（CPU、記憶體）有限, 動態建立大量子進程會造成效能負擔，進而影響整體韌體的穩定性與反應速度。
- 服務管理：
systemd提供了更完整的服務生命週期管理（啟動、監控、失效自動重啟等）與錯誤處理能力（如 restart policy、watchdog 等）。
👉（這部分我們會在後續聊systemd的章節中詳細介紹, 它在 OpenBMC 韌體架構中扮演了關鍵角色。） - 穩定性與低耦合性：為了避免多個 process 之間產生複雜依賴與資源共享問題, OpenBMC 系統傾向讓每個服務 process 擁有明確且獨立的執行範疇。
例如：
我在過去的 code review 中經常看到類似問題：某個 A process 修改了某個全域變數或共享資源, 而另一個 B process 也依賴同一個記憶體位置。若任一方寫錯, 就可能導致彼此的行為失常。
這種跨 process 的「隱性耦合」, 會讓錯誤擴散難以追蹤：
- 問題來源不明 → debug 變得困難
- 修復時需考慮連鎖影響 → 無法單點修正
當不同 process 的功能原本是彼此獨立, 卻因為共享記憶體、檔案或同步機制而產生耦合, 整體系統的穩定性與維護成本就會大幅上升。
