底層邏輯：從蠑螈到 OpenBMC

Yocto_嵌入式開發環境建置實務

海邊の蠑螈 — Sat, 25 Apr 2026 01:12:41 GMT

Yocto Project 開發環境的建置實務，詳細介紹了從硬體選擇、作業系統配置到自動化工具使用的關鍵步驟，旨在幫助開發者建立一個穩定且高效的「嵌入式系統生產基地」。

1. 硬體資源：量力而為的「軍備競賽」

多核心處理器：Yocto 的編譯引擎 BitBake 支援高度平行運算，建議至少使用 16 核心以上的 CPU。
記憶體 (RAM)：編譯重型軟體（如 WebKit 或 LLVM）極度消耗記憶體，建議配置 32GB 或更高等級，否則容易因 OOM (Out of Memory) 導致編譯中斷。
硬碟空間與速度：建議至少預留 200GB 到 500GB 的 SSD 空間，因為編譯過程中會產生大量的中間檔案與暫存資料。

2. 作業系統與環境隔離

Linux 發行版選擇：官方強烈建議使用原生 Linux（如 Ubuntu LTS），以確保與 Yocto 各項工具鏈的相容性。
環境標準化 (Docker)：為了避免開發者個人主機環境（如相依庫版本不同）干擾編譯結果，使用 Docker 容器來統一團隊的建構環境已成為業界標準。
WSL2 的應用：針對 Windows 使用者，WSL2 提供了一個高效且便利的折衷方案，讓開發者能在熟悉的視窗介面下進行重度 Linux 開發。

3. 加速開發的基礎設施

SState Cache (共享快取)：透過架設中央快取伺服器，讓團隊成員能下載已編譯好的成品，節省重複編譯的時間。
DL_DIR (原始碼快取)：將所有下載的原始碼集中管理，避免因網路不穩或上游伺服器斷線而影響建構進度。

4. 必備的基礎工具

建構依賴套件：在開始前必須安裝如 build-essential, python3, git, diffstat, texinfo 等基礎開發工具。
CROPS 方案：這是一個專為非 Linux 系統設計的框架，利用容器技術讓開發者能跨平台啟動 Yocto 建置環境。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_開發環境生存指南

海邊の蠑螈 — Fri, 24 Apr 2026 01:09:30 GMT

OpenBMC 開發者的「生存指南」，深入探討了建置開發環境時的技術挑戰、硬體需求以及如何利用 Yocto Project 的特性來優化工作流程。

1. 為什麼 OpenBMC 開發環境很「硬」？
龐大的編譯規模：OpenBMC 不僅僅是一個軟體，它是一個完整的 Linux 發行版。編譯過程涉及下載與構建數千個套件，對硬體資源要求極高。
硬體規格建議：

CPU：建議至少 16 核心以上的處理器，因為 BitBake 能平行處理多個任務。
記憶體：建議 32GB RAM 以上，避免在編譯重型套件（如 WebUI 或 LLVM）時因記憶體不足而崩潰。
硬碟空間：至少預留 100GB 到 200GB 的 SSD 空間，因為編譯過程中會產生大量的中間檔案。

2. 作業系統與工具鏈選擇

WSL2 的崛起：對於 Windows 使用者，WSL2 是目前開發 OpenBMC 的首選，它能提供接近原生 Linux 的效能，同時兼顧 Windows 的辦公便利性。
Docker 容器化：為了避免不同開發者之間的環境污染，使用 Docker 來標準化編譯環境已成為企業級開發的常態。

3. 利用 Yocto 特性加速開發

SState Cache (共享快取)：這是開發者的「救命恩人」。透過建立伺服器端的快取，開發者只需下載別人編譯過的成品，不必每次都從頭開始。
Devtool 的實戰應用：指南強烈建議學會 devtool。它允許開發者在不啟動完整編譯的情況下，快速修改某個 D-Bus 服務的程式碼並直接部署到 BMC 上測試。

4. 虛擬化除錯技術

QEMU 模擬器：在沒有實體伺服器板子的情況下，利用 QEMU 模擬 ASPEED 晶片環境，可以先行測試核心開機邏輯與基本的 D-Bus 通訊。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

BitBake_嵌入式系統中央大腦

海邊の蠑螈 — Thu, 23 Apr 2026 03:00:59 GMT

將 BitBake 喻為嵌入式系統的「中央大腦」，深入探討了其作為 Yocto Project 核心引擎的運作邏輯與任務排程機制。

1. BitBake：嵌入式系統的指揮官

核心定義：BitBake 是一個強大的任務執行引擎與建構工具，負責解析大量複雜的食譜（Recipes）與設定檔。
決策中心：它像大腦一樣，能理解各個軟體組件之間的依賴關係，並決定在什麼時間點、以什麼順序執行哪些編譯任務。

2. 任務排程與依賴管理

任務分割：BitBake 將建構流程拆解為無數個細小的任務（如 do_fetch, do_compile, do_install），實現高度的自動化控管。
處理複雜依賴：它能自動理清成千上萬個套件之間的先後順序，確保所有基礎庫（Library）都在應用程式編譯前準備就緒。

3. 高效能與並行運算

多工處理：BitBake 支援並行建構，能充分利用多核心 CPU 的效能，同時處理多個互不干擾的任務，大幅縮短整體編譯時間。
智慧判斷：配合「數位指紋」機制，BitBake 僅會執行內容發生變動的任務，避免無謂的資源浪費。

4. 變數與設定的解析

環境控管：BitBake 負責解析龐大的變數系統，將全域設定與特定硬體（BSP）的參數完美結合，確保生成的系統鏡像完全符合預期。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

BitBake_數位指紋終結編譯混亂

海邊の蠑螈 — Wed, 22 Apr 2026 02:59:44 GMT

深入探討 BitBake 引擎如何利用「數位指紋」機制來解決嵌入式系統編譯中的混亂，並確保建構過程的高度精確性與效率。

1. 數位指紋 (Hash) 的核心角色

唯一標識：BitBake 會為每一個建構任務計算一組數位指紋（Hash），這組指紋就像是任務的身份證，代表了該任務所有的輸入條件。
變動追蹤：只要輸入內容（如程式碼、環境變數、編譯參數）有任何微小的變動，數位指紋就會隨之改變，確保系統能精準偵測到需要重新編譯的部分。

2. 終結編譯混亂的機制

精準依賴管理：透過數位指紋，BitBake 能夠理清成千上萬個任務之間複雜的相依關係，避免無效的重複勞動。
確保一致性：數位指紋機制保證了「輸入相同，產出必相同」的原則，這對於開發大規模嵌入式系統時維持版本穩定至關重要。

3. SState Cache 的運作基礎

加速編譯：系統會比對當前任務的指紋與緩存（Cache）中的紀錄。如果指紋完全匹配，BitBake 就會直接抓取預先編譯好的成品，而不需要重新跑一遍耗時的編譯流程。
排除環境干擾：指紋機制能過濾掉與建構邏輯無關的雜訊（如檔案時間戳記、主機使用者名稱），讓編譯結果更加純粹且可重現。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_暴力重啟與可重現建置

海邊の蠑螈 — Tue, 21 Apr 2026 02:58:46 GMT

深入探討 Yocto Project 如何處理建構過程中的「暴力中斷」情況，以及其核心價值之一：可重現建置（Reproducible Builds）。

1. 處理暴力重啟的韌性

狀態一致性：Yocto 的建構引擎 BitBake 具有極強的韌性，即使在編譯中途遭遇斷電或人為強制中斷，它也能透過追蹤任務狀態，在重啟後準確地從上次中斷點繼續執行。
原子化操作：每個建構任務都被設計為原子化操作，確保不會因為中斷而產生損壞的半成品，維持工作目錄的整潔與正確性。

2. 可重現建置（Reproducible Builds）

二進位一致性：這是 Yocto 的最高目標之一。無論是在哪台機器、哪個時間點進行建構，只要輸入（原始碼、設定檔、環境變數）相同，產出的二進位檔案（Binary）就必須完全一致。
消除環境變數干擾：Yocto 透過極其嚴格的隔離機制，過濾掉主機環境的影響（如路徑、時間戳記、使用者名稱等），確保產出的系統鏡像（Image）是完全可預測的。
安全性與信任：可重現性讓開發者能驗證編譯產物是否遭到竄改，這對於供應鏈安全至關重要。

3. 實務操作技巧

強制重新執行：介紹了如何使用 -f（force）或 -c clean 等指令，強制系統捨棄舊有的狀態記錄，從頭開始乾淨的建構流程。
檢查可重現性：利用 Yocto 內建的測試工具（如 reproducible_builds.bbclass），自動比對兩次建構產出的差異，確保系統達到真正的可重現標準。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Toaster_給你_Yocto_編譯上帝視角

海邊の蠑螈 — Mon, 20 Apr 2026 02:56:30 GMT

介紹 Toaster，它是 Yocto Project 中的一個網頁圖形介面工具，旨在為複雜的編譯過程提供「上帝視角」，讓開發者能更直觀地管理與分析建構流程。

1. 什麼是 Toaster？

視覺化儀表板：Toaster 是一個網頁介面，它將原本在終端機（Terminal）跑過的密密麻麻文字訊息，轉化為易於閱讀的圖表與數據。
上帝視角：它記錄了每一次建構的詳細資訊，讓開發者不再只是「盲目編譯」，而是能掌握全盤狀況。

2. Toaster 的核心功能
建構歷史記錄：自動記錄過去所有執行過的 bitbake 任務，包括成功的與失敗的，方便進行回溯對比。
效能瓶頸分析：

耗時統計：明確顯示各個任務（Tasks）的執行時間，找出誰是拖慢編譯速度的元兇。
資源消耗：監控 CPU 與磁碟 I/O 的使用情況，優化硬體資源分配。

軟體套件審核：

套件清單：列出最終鏡像檔（Image）中包含的所有軟體套件及其版本。
依賴關係圖：以視覺化方式呈現套件之間的複雜依賴關係，幫助清理不必要的元件。
授權追蹤：再次確認所有套件的開源授權是否合規，降低法律風險。

3. 使用場景與優勢

錯誤診斷：當編譯失敗時，Toaster 會集中顯示錯誤訊息並提供相關日誌的快速連結，縮短除錯時間。
團隊共享：Toaster 可以架設在伺服器上，讓整個團隊共享編譯結果與分析數據，提升協作效率。
專案配置管理：允許透過網頁介面調整變數（Variables）或添加層（Layers），雖然資深開發者習慣指令列，但對於新手或專案經理來說更為友善。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_eSDK_讓軟硬體開發脫鉤

海邊の蠑螈 — Sun, 19 Apr 2026 02:54:41 GMT

介紹 eSDK (Extensible SDK)，這是 Yocto Project 中一項關鍵技術，旨在解決嵌入式開發中「軟硬體開發過度耦合」的痛點，讓應用層開發者能與底層系統開發同步並行。

1. 核心價值：軟硬體開發脫鉤

傳統開發瓶頸：在過去，應用程式開發者必須等待底層系統（BSP）完全建置完成，並拿到龐大且笨重的工具鏈後才能開始工作。
eSDK 的解決方案：它提供了一個輕量、可擴充且自給自足的開發環境，包含了目標硬體所需的庫（Libraries）、標頭檔（Headers）以及專屬的編譯工具。

2. eSDK 的關鍵特性

自帶編譯器與工具鏈：eSDK 內建了針對目標硬體優化的交叉編譯工具，開發者無需在自己的主機上安裝複雜的 Yocto 建構環境。
與 BitBake 環境共享快取：eSDK 能利用 Yocto 的共享快取機制。如果底層系統已經編譯過某個庫，eSDK 會直接使用成品，大幅縮短應用程式的開發循環。
整合 Devtool：這是 eSDK 最強大的地方。開發者可以利用 devtool 在 eSDK 中快速修改程式碼、編譯並直接部署到目標板上進行測試，而無需重新啟動完整的 Yocto 建構流程。

3. 對開發流程的影響

並行開發：底層工程師負責優化核心與驅動，應用層工程師則利用 eSDK 同步開發功能，雙方只需透過標準的 API 介面對接，互不干擾。
降低門檻：不熟悉 Yocto 複雜架構的應用軟體工程師，只需像使用一般 SDK 一樣操作 eSDK，即可開發出能在特定嵌入式系統上運行的程式。
持續整合 (CI) 友善：eSDK 體積相對較小且易於分發，非常適合整合進自動化測試與 CI 流水線中。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_嵌入式系統效能除錯實戰

海邊の蠑螈 — Sat, 18 Apr 2026 02:53:58 GMT

深入探討在 Yocto Project 環境下，如何進行嵌入式系統的效能優化與除錯實務，並將複雜的除錯過程比喻為「科學家的實驗室」。

1. 效能優化的核心思維

數據導向：強調在優化前必須先進行量化測量，不能憑感覺，要找出真正的效能瓶頸（Bottleneck）。
系統級優化：優化不只是修改程式碼，還包括調整 Linux 核心參數、減少不必要的背景服務以及優化開機流程。

2. 關鍵除錯與分析工具
Profiling（剖析）：

Perf：用於分析 CPU 週期，找出哪些函數最佔用資源。
LTTng：提供系統級的追蹤，觀察行程（Process）之間的互動與中斷（Interrupt）延遲。

Visualization（視覺化）：

Bootchart：專門用於分析開機流程，以圖表方式呈現各服務啟動的先後順序與耗時。
Flame Graphs（火焰圖）：直觀顯示函數呼叫堆疊及其效能佔比。

3. Yocto 特有的除錯機制

devshell：提供一個獨立的終端機環境，讓開發者能在 BitBake 的建構環境中直接進行編譯與測試。
DEBUG_BUILD 變數：透過設定此變數，可以移除編譯優化並保留除錯符號（Debug Symbols），方便使用 GDB 進行追蹤。
GDB Remote Debugging：介紹如何利用目標板上的 gdbserver 與開發主機上的 GDB 進行遠端除錯。

4. 實戰除錯技巧

分而治之：透過層級（Layers）的開關，快速定位問題是出在硬體驅動（BSP）還是上層應用程式。
日誌分析：利用 Yocto 產生的詳細建構日誌（Logs）來追蹤編譯階段的錯誤。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_實戰砍掉八成核心漏洞誤報

海邊の蠑螈 — Fri, 17 Apr 2026 02:48:49 GMT

深入探討如何利用 Yocto Project 的機制來優化 CVE（常見漏洞與披露）掃描流程，特別是解決開發者最頭痛的「大量誤報」問題，提升資安管理的實戰效率。

1. 核心挑戰：CVE 掃描的誤報困境

版本誤判：傳統掃描工具常因軟體版本號定義模糊，將已修補的舊版本誤認為仍具威脅。
無效警報：掃描結果往往包含大量與當前硬體架構或功能無關的漏洞，導致開發者陷入處理「假警報」的循環。

2. Yocto 的解決方案：精準控管與排除
CVE_CHECK_WHITELIST (白名單)：

精準排除：對於經確認不影響當前系統，或已透過其他方式防護的漏洞，可透過白名單機制永久排除，不再重複報錯。
原因記錄：在排除的同時，建議記錄排除原因（例如：硬體不支援該功能），確保未來審核時有跡可循。

CVE_STATUS (狀態標記)：

細粒度管理：Yocto 5.3 以後的版本提供更強大的狀態標記功能，可以標註漏洞為「已修補」、「不受影響」或「正在處理中」。
自動化整合：這些狀態能直接整合進 SBOM（軟體物料清單），提供透明的安全合規報告。

3. 實戰砍掉八成誤報的技巧

過濾非必要組件：利用 Yocto 的高度客製化特性，剔除不需要的功能模組，從根本上減少攻擊表面與潛在漏洞數。
使用 Patch 解析機制：Yocto 具備自動解析 .patch 檔案內容的能力，能識別開發者是否已手動套用安全修補程式，進而自動消除已解決的漏洞警報。

4. 建立「資安上帝視角」

持續監控：將 CVE 掃描整合進 CI/CD 自動化流程，每次編譯都產出最新的資安健康報告。
Toaster 視覺化分析：透過 Toaster 網頁介面，能直觀地查看漏洞在不同套件間的分佈，優先處理高風險（High/Critical）項目。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_讓_Linux_核心像拼樂高

海邊の蠑螈 — Thu, 16 Apr 2026 02:51:08 GMT

將 Yocto Project 處理 Linux 核心的過程比喻為「拼樂高」，深入探討了其獨特的 Linux Kernel 開發機制，以及如何透過高度模組化的方式來管理複雜的核心配置。

1. 核心開發的「樂高化」哲學

模組化配置：Yocto 不建議直接修改巨大的核心原始碼，而是將各種功能（如驅動程式、檔案系統支援）拆解成細小的配置片段（Configuration Fragments）。
精準堆疊：開發者可以像拼積木一樣，根據需求選擇不同的 .cfg 檔案進行堆疊，最終組合成完整的核心設定。

2. 關鍵技術機制

Config Fragments (.cfg)：這些細小的設定檔只包含特定功能的開關（如 CONFIG_USB=y），讓管理變得極其簡單且易於複用。
SRC_URI 與 Patch 系統：透過食譜中的 SRC_URI 變數，系統能精確地將特定硬體所需的修補程式（Patches）自動套用到原始核心上。
KBUILD 與 KCONFIG 的整合：Yocto 完美橋接了 Linux 核心原生的建構系統，確保生成的編譯參數符合硬體需求。

3. 開發者的「便利貼」機制

.bbappend 的妙用：利用 .bbappend 檔案，開發者可以在不變動官方核心食譜的情況下，額外增加自定義的配置或 Patch，實現極高的開發彈性。
維護性提升：這種「非侵入式」的修改方式，讓未來升級新版核心時，衝突的可能性降到最低。

4. 實務價值
跨平台遷移：透過更換底層的配置片段，同一套系統邏輯可以迅速從一個開發板遷移到另一個完全不同的硬體架構上。
最小化系統核心：開發者能輕鬆剔除不需要的功能，打造出體積極小、開機極快的優化核心。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_打造防彈_Linux_系統

海邊の蠑螈 — Wed, 15 Apr 2026 02:43:31 GMT

深入探討如何利用 Yocto Project 打造安全性極高、如同「防彈」般的嵌入式 Linux 系統，重點在於自動化漏洞管理與軟體供應鏈的透明化。

1. 自動化安全性漏洞控管

CVE 檢查機制：Yocto 內建了自動化的 CVE（常見漏洞與披露）掃描工具。開發者只需在建構環境中繼承 cve-check 類別，系統就會自動比對全球漏洞資料庫。
即時風險預警：在編譯過程中，如果發現使用的套件版本存在已知漏洞，系統會立即產出詳細報表，指明哪些元件受威脅以及是否有可用的修補食譜（Recipes）。

2. 軟體供應鏈安全與合規

SBOM（軟體物料清單）：Yocto 能夠自動生成完整的 SBOM，詳細記錄系統中每個元件的來源、版本及授權條款。這對於應對如歐盟《網路韌性法案》（CRA）等法律規範至關重要。
授權合規檢查：透過 LICENSE 變數與 MD5 效驗碼機制，系統強制要求每個食譜必須明確標註授權，防止法律風險與授權文件被惡意竄改。

3. 建構防彈系統的技術手段

最小化系統鏡像：透過 Yocto 的高度客製化能力，開發者可以剔除所有不必要的背景服務與通訊埠，大幅縮小攻擊表面。
二進位一致性（Reproducible Builds）：確保輸入相同則產出完全一致。這讓開發者能驗證編譯產物是否在過程中遭到竄改，建立完整的技術信任鏈。
安全加固工具：支援整合 SELinux、AppArmor 以及硬體信任根（Root of Trust），從底層強化系統防禦力。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_BSP_底層開發與授權實務

海邊の蠑螈 — Tue, 14 Apr 2026 06:06:53 GMT

深入探討 Yocto Project 在 BSP（板級支援包）開發與開源授權合規方面的實務操作，強調了硬體與軟體層級分離的重要性。

1. BSP（Board Support Package）的核心價值

硬軟體解耦：BSP 層的主要任務是將硬體細節（如核心、驅動程式、啟動載入器）與上層的發行版策略分離。
高度客製化：透過建立專屬的硬體支援層（通常命名為 meta-），開發者可以針對特定晶片（如 ARM 或 x86）進行優化。
核心配置與修補：詳細介紹了如何透過 Yocto 的食譜（Recipes）對 Linux 核心進行配置（.config）與打補丁（Patching），以支援特定的周邊硬體。

2. 開源授權合規實務

法律風險控管：在商業產品中，確保所有使用的開源軟體都符合授權規範至關重要。
LICENSE 變數：Yocto 強制要求每個食譜都必須明確標註授權類型（如 MIT, GPLv2），否則會導致編譯失敗。
自動生成授權清單：系統能自動追蹤並產出產品中包含的所有軟體授權清單，方便法務人員審核。

3. 專案開發的最佳實踐

建立自定義層：不建議直接修改官方層級，應建立自己的層級並使用 _append 功能來擴充功能，以利未來系統升級。
層級優先順序（Priority）：解釋了如何透過優先權設定，確保自定義的硬體配置能正確覆蓋掉預設設定。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_核心變數精準控管系統建置

海邊の蠑螈 — Mon, 13 Apr 2026 06:03:09 GMT

深入探討 Yocto Project 中最核心也最複雜的變數控管系統，將其比喻為一套精密的「中央情報處理中心」，負責協調數萬個建構參數。

1. 變數的核心地位

系統的導航儀：在 Yocto 中，變數決定了從原始碼下載路徑、編譯參數到最終鏡像檔大小的所有行為。
元數據 (Metadata)：變數本身就是一種元數據，透過精確的定義，讓 BitBake 知道如何在複雜的環境中執行正確的建構邏輯。

2. 高階賦值運算子 (Operators)

立即賦值 (:=) 與延遲賦值 (=)：立即賦值會直接鎖定當下數值，而延遲賦值則會等到最後使用時才解析，這在處理具有依賴關係的變數時至關重要。
預設賦值 (?=) 與弱賦值 (??=)：這允許開發者提供預設選項，同時保留被其他層級 (Layers) 覆蓋的彈性，是維持 Yocto 靈活性與可維護性的關鍵。

3. 字串操作與附加機制

加入與追加 (+=, .=, _append, _prepend)：Yocto 提供了多種方式來修改變數內容，特別是 _append 機制，它能確保在不破壞原始定義的情況下，安全地增加編譯參數或相依項目。

4. 變數的覆蓋與優先順序 (Overrides)

特定條件下的變數選擇：利用「條件覆蓋」機制（如針對特定硬體架構或作業系統發行版），系統能自動選擇最合適的變數數值，實現「一套食譜，多種產出」的目標。

5. 精準控管的實務意義

減少建構錯誤：透過嚴格的變數追蹤與語法檢查，能大幅減少因環境設定錯誤導致的編譯失敗。
提升開發透明度：完善的變數控管讓複雜的嵌入式開發過程變得可預測且易於審核。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_5.3 核心架構與開發流程

海邊の蠑螈 — Sun, 12 Apr 2026 06:01:13 GMT

深入探討 Yocto Project 5.3 的核心架構，將複雜的自動化建構流程比喻為一座高度精密且具有「機制優先」特性的自動化生產線。

1. Yocto 的核心架構：自動化生產線

BitBake 建構引擎：扮演生產線控制器的角色，負責解析食譜（Recipes）並管理成千上萬個任務的依賴關係。
層級（Layers）管理：採用模組化設計，將硬體支援（BSP）、軟體策略（Distro）與應用程式分開，確保開發者在不更動核心系統的情況下進行客製化。
Poky 參考發行版：作為 Yocto 的標準範例，提供了一套經過驗證的開發工具、基礎食譜與建構環境。

2. 開發流程的關鍵階段

獲取與解包（Fetch & Unpack）：BitBake 根據食譜抓取原始碼，並建立獨立的工作目錄，避免環境污染。
打補丁與配置（Patch & Configure）：套用開發者客製化的修改，並針對目標硬體架構（如 ARM 或 x86）進行配置。
交叉編譯（Cross-Compilation）：在強大的 X86 主機上，為資源有限的嵌入式設備編譯出專用的機器碼。
封裝與生成鏡像（Packaging & Image Generation）：將編譯好的檔案打包成 RPM 或 IPK 格式，最後組合成可燒錄的系統鏡像檔。

3. 高階管理機制

機製優於策略（Mechanism over Policy）：Yocto 提供工具（機制），但將決定權（策略）留給開發者，讓系統能適應從路由器到醫療儀器等各種不同需求。
版本控制與溯源：透過嚴格的食譜定義，確保建構過程具備高度的可重現性，方便追蹤程式碼變動與進行安全審核。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_嵌入式系統量產兵工廠

海邊の蠑螈 — Sat, 11 Apr 2026 05:44:30 GMT

將 Yocto Project 比喻為一座「嵌入式系統量產兵工廠」，深入探討了其在企業級開發中的核心價值，特別是在可複製性、安全性與團隊協作方面的優勢。

1. 核心哲學：可複製性 (Reproducibility)

消失的「我的電腦可以跑」： Yocto 解決了軟體開發中常見的環境差異問題。透過精確的食譜（Recipes）與層級（Layers）設定，確保全球不同地區、不同時間點編譯出的系統鏡像（Image）完全一致。
數位指紋檢驗：系統利用數位指紋（Hash）監控每一個組件，只要輸入條件不變，產出的結果就必須相同，這對於需要長期維護（LTS）的嵌入式產品至關重要。

2. 企業級安全保障

CVE 漏洞自動掃描：兵工廠內建了自動化監測工具，能比對全球已知的安全性漏洞（CVE）。開發者可以快速得知當前系統版本是否存在風險，並尋找對應的修補食譜。
法律合規與 SBOM：系統能自動生成「軟體清單」（SBOM），詳列所有元件的授權條款（如 MIT, GPL）。這防止了公司因誤用開源授權而面臨法律訴訟，是產品外銷歐美的必備條件。

3. 高效率的協作流水線

SState Cache（共享冷凍庫）：企業內部可以架設共享緩存伺服器。當一名工程師編譯過某個核心組件後，其他同事只需直接下載成品，節省數小時的編譯時間。
機制高於策略： Yocto 強制執行一致的開發規範，讓新進工程師只要看懂食譜結構，就能快速上手維護前人留下的專案。

4. 為什麼是「兵工廠」？

標準化生產：它不只是寫程式，而是建立一整套工業化的系統生產流程。
模組化彈性：透過更換硬體支援層（BSP Layer），同一套應用軟體可以迅速適應不同的晶片平台（如從 ARM 轉向 x86）。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

操控萬台伺服器的超級遙控器_Redfish

海邊の蠑螈 — Sat, 11 Apr 2026 03:47:12 GMT

將 Redfish API 比喻為「操控萬台伺服器的超級遙控器」，深入探討了這項現代化管理標準如何取代傳統的 IPMI，成為資料中心自動化運維的核心。

1. 什麼是 Redfish？

新一代管理標準：Redfish 是由 DMTF 組織定義的一套標準，旨在取代過時且難以擴展的 IPMI 協定。
基於 RESTful API：它採用了互聯網通用的技術架構，如 HTTP(S)、JSON 與 OData，讓伺服器管理就像呼叫網頁 API 一樣簡單。

2. 為何需要 Redfish？（解決 IPMI 的痛點）

可擴展性不足：IPMI 原本是為單機設計的，無法應對現代資料中心數萬台伺服器的管理需求。
安全性疑慮：IPMI 的設計年代較早，存在多種已知的安全漏洞，且加密強度不足。
廠商不相容：過去各家硬體廠商的 IPMI 指令常有落差，導致維運人員需要針對不同品牌撰寫多套腳本。

3. Redfish 的核心優勢

人類可讀的資料格式：使用 JSON 格式傳輸數據，開發者能一眼看懂硬體狀態（如溫度、風扇轉速、電力消耗）。
跨平台相容性：無論是 Dell、HP、IBM 還是白牌伺服器，只要支援 Redfish，就能使用同一套標準化工具進行管理。
強大的自動化整合：能輕鬆與 Ansible、Terraform 等現代化運維工具整合，實現「基礎設施即程式碼」（Infrastructure as Code）。
支援複雜硬體：除了傳統伺服器，Redfish 也能擴展到管理 GPU 加速器、網路交換器與存取設備。

4. 產業影響力

資料中心數位轉型：Redfish 是雲端服務商（如 Google、Meta）實現全自動化機房管理的關鍵技術基礎。
與 OpenBMC 的聯手：OpenBMC 專案全面採用 Redfish 作為預設的管理介面，進一步推動了伺服器底層管理的開放與標準化。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_硬派_Email_協作法則

海邊の蠑螈 — Fri, 10 Apr 2026 05:43:04 GMT

深入解析 Yocto Project (版本 5.3-tip) 的貢獻者指南，揭示了這個龐大開源專案背後嚴謹甚至「硬派」的協作文化。

1. 精準的問題定位（Component & Layer）

不找總客服： Yocto 由多個層級（Layers）組成，發生問題時必須先識別受影響的組件。
層級劃分：硬體問題找 BSP 層；系統設定或編譯問題找 Distro 層；底層核心錯誤才找核心層或 BitBake。
過濾噪音：這種機制強迫回報者先做初步過濾，因為開源維護者時間有限，無法處理描述模糊的問題。

2. 「生化實驗」般的食譜規範 (Recipe Style)

極致的細節：為了確保「冪等性（Idempotency）」（無論何時何地編譯，結果必須完全一致），食譜中的命名、格式、等號兩邊的空白都有嚴格規定。
波浪號（~）的魔力：在版本命名中使用波浪號能確保測試版（如 RC2）在系統排序中正確排在正式版之前，避免版本升級邏輯錯誤。
法律防火牆：強制要求對授權文件進行 MD5 效驗碼比對。一旦上游授權條款有微小變動（如從 MIT 改為 GPL），編譯會立即報錯當機，以防止公司面臨法律風險。

3. 硬派的「純文字 Email」協作

捨棄 GitHub UI：為了維護大師級維護者（Maintainers）的高效工作流，Yocto 堅持使用電子郵件論壇提交程式碼（Patches）。
同儕審查（Peer Review）：公開郵件清單能讓數百位專家同時審視代碼，提高抓錯效率。
禁止排版自動修整：嚴禁使用 Outlook 或 Gmail 等會自動修改空白或格式的軟體，必須使用 git send-email 指令發送，以確保自動化工具能無縫接收。

4. AI 時代的責任歸屬

可以請 AI 寫，但人要扛責：允許使用 AI 輔助產生食譜，但必須在提交訊息中明確標註 signed-off-by。
問責機制：最終負責法律與技術正確性的是簽名的「人類」，而非機器。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_伺服器幕後總監

海邊の蠑螈 — Fri, 10 Apr 2026 03:45:21 GMT

將 OpenBMC 描述為「伺服器的幕後總監」，深入探討了其作為開源基板管理控制器（BMC）韌體堆疊的核心地位，以及它如何改變現代資料中心的管理模式。

1. OpenBMC 的定義與角色

伺服器的獨立管家：OpenBMC 是一個開源項目，運作在主機 CPU 之外的獨立小處理器上，負責在作業系統未啟動或發生故障時，依然能監控與管理伺服器。
打破封閉生態：它由 Linux 基金會支持，旨在取代傳統硬體廠商提供的「黑盒子」式封閉韌體，提供透明且可客製化的管理方案。

2. 核心技術架構

基於 Linux 與 Yocto：OpenBMC 是一個完整的 Linux 發行版，利用 Yocto Project 的層級（Layer）機制來構建，這使得它能輕鬆適應不同廠牌的 BMC 晶片。
D-Bus 通訊機制：系統內部採用 D-Bus 匯流排讓各個獨立的程序（如風扇控制、溫度監控）進行通訊，這種結構大幅提升了開發的靈活性。
標準管理協定：全面支援 Redfish、IPMI 與 HTTP/HTTPS 等協定，讓自動化運維變得更加簡單。

3. OpenBMC 的三大優勢

安全性與透明度：開源程式碼讓全球安全專家能共同審核，大幅降低了潛在的後門風險，並支持硬體信任根（Root of Trust）的建立。
開發效率與一致性：開發者可以使用標準的 Linux 工具進行開發，且同一套代碼能跨平台運行，減少了重複造輪子的成本。
避免供應商綁定：企業可以根據自己的需求修改韌體，不再受限於硬體供應商的軟體更新週期。

4. 產業影響力

科技巨頭聯手推動：由 Google、Facebook (Meta)、Intel、IBM、Microsoft 等巨頭共同投入資源，已成為超大規模資料中心（Hyperscale Data Centers）的實質標準。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Yocto_嵌入式_Linux_開發機制

海邊の蠑螈 — Thu, 09 Apr 2026 05:36:56 GMT

深入淺出地介紹 Yocto Project 的核心概念與運作機制。它將複雜的嵌入式 Linux 開發比喻為「蓋房子」與「經營餐廳」，讓技術門檻極高的 Yocto 變得易於理解。

1. 為什麼需要 Yocto？（手術刀 vs. 瑞士刀）

傳統桌面 Linux（如 Ubuntu/Debian）：像是功能齊全但臃腫的「瑞士刀」，強行塞進資源受限的嵌入式設備會導致開機慢、效能低。
Yocto Project：則像是精準的「手術刀」，提供工具與藍圖，讓開發者能為特定硬體量身打造極簡、高效的 Linux 系統。

2. Yocto 的核心三要素（廚房比喻）

BitBake（主廚）：整個系統的心臟，是一個具有強迫症的任務執行引擎，負責按照食譜精確執行編譯與打包。
Recipe（食譜）：副檔名為 .bb 的檔案，詳細記錄了軟體的原始碼來源、修補程式（Patch）以及編譯參數。
Poky（示範菜單）： Yocto 官方提供的標準示範環境，包含主廚、基礎食譜與環境設定，但不建議直接用於正式產品。

3. 層級架構與複寫機制 (Layer & Override)

Layer Model（抽屜）：以 meta- 開頭的資料夾，將發行版設定、軟體食譜與硬體支援（BSP）分開管理。
.bbappend（便利貼）：允許開發者在不更動原始食譜的情況下，透過「便利貼」複寫或增加設定，維持系統的可維護性與升級彈性。

4. 加速開發的黑科技：SState Cache

數位指紋： BitBake 會為每個任務計算數位指紋（Hash），若輸入條件完全沒變，就會直接從「冷凍庫」（Cache）拿取編譯好的成品。
Hash Equivalence：即使程式碼加了空白或註解導致指紋改變，若最終輸出的執行檔一致，系統也會聰明地停止「骨牌效應」，避免不必要的重新編譯。

5. 現代化開發工具

Devtool：解決了傳統 Yocto 編譯緩慢的痛點。它能將軟體抽離到「沙盒」中讓開發者快速修改、測試，再一鍵將結果導回 Yocto 流程。
VS Code 整合：透過官方擴充套件，提供食譜語法高亮與補全，大幅降低學習曲線。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

用_QEMU_讓韌體開發像寫軟體

海邊の蠑螈 — Tue, 07 Apr 2026 05:47:30 GMT

深入探討 QEMU (Quick Emulator) 在 OpenBMC 韌體開發中的關鍵角色。透過虛擬化技術，它打破了硬體資源的限制，讓韌體開發流程能夠像現代軟體開發一樣高效且自動化。

以下是錄音內容的重點摘要：
1. 韌體開發的傳統痛點

硬體依賴性強：早期開發者必須在昂貴且數量有限的實體伺服器（EVT/DVT 階段機器）上進行測試。
燒錄時間冗長：每次修改程式碼後，都需要花費數分鐘甚至更久來燒錄 Flash，導致開發迭代速度緩慢。
環境不穩定：硬體電路問題與軟體錯誤常混雜在一起，難以快速定位 Bug。

2. QEMU 的核心優勢

虛擬試車場：QEMU 能模擬 ARM 或 x86 架構的 BMC 處理器，開發者在一般筆電上就能執行 OpenBMC 映像檔。
即時模擬硬體行為：支援模擬各種周邊介面（如 I2C, SPI, UART, NIC），甚至能模擬風扇轉速與溫度感測器的數值變化。
快速迭代：修改程式碼後可直接載入虛擬環境，省去物理燒錄時間，大幅提升開發效率。

3. CI/CD 與自動化測試

大規模平行測試：由於不需要實體機，開發社群能在雲端環境同時開啟數百個 QEMU 實體，進行自動化回歸測試。
穩定性保障：透過 QEMU 進行「嗅覺測試 (Sniff Test)」，確保每次程式碼合併都不會導致系統無法開機或核心功能故障。
異常情境模擬：開發者能輕易模擬在實體機上難以重現的故障（如硬體逾時、記憶體損壞），驗證韌體的容錯能力。

4. 開發者的「心理安全感」

容許錯誤：在 QEMU 中弄壞系統只需重開模擬器，不用擔心導致實體硬體損壞（如變磚或燒毀）。
透明度高：利用 GDB 等除錯工具，開發者能精確觀測虛擬 CPU 的暫存器與記憶體狀態，這是實體機難以企及的透明度。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

SPDM_伺服器硬體安全與效能優化

海邊の蠑螈 — Tue, 07 Apr 2026 05:40:02 GMT

深入探討 SPDM (Security Protocol and Data Model) 協定在現代伺服器管理中的關鍵角色，特別是它如何為硬體組件提供安全身分驗證，並在不犧牲效能的前提下強化系統安全性。

以下為該錄音內容的重點整理：
1. SPDM 的核心定義與起源

定義：SPDM 是一套由 DMTF 定義的標準協定，主要用於基板管理控制器（BMC）與伺服器組件（如網卡、顯卡、SSD）之間的安全性溝通。
目標：確保伺服器內部的每一個硬體零件都是「原廠正品」且「未被竄改」。

2. 三大安全支柱

身分驗證 (Authentication)：透過數位憑證確認組件身分，防止偽造硬體混入系統。
韌體量測 (Measurement)：系統會檢查組件韌體的雜湊值（Hash），確保韌體版本與官方紀錄一致，防止惡意後門。
建立安全連線 (Secure Session)：在驗證通過後，建立加密通道進行資料傳輸，防止敏感數據被截聽。

3. 效能與安全的權衡優化

輕量化設計：不同於一般網路使用的 TLS 協定，SPDM 專為硬體通訊設計，大幅減少了交握（Handshake）過程中的運算開銷。
二進位格式：採用精簡的二進位封包，非常適合在頻寬有限的 I2C、SMBus 或 PCIe 介面上運行。

4. 與 MCTP 的協作

SPDM 通常承載於 MCTP (Management Component Transport Protocol) 之上，這讓它具備優異的傳輸層靈活性，能跨越不同硬體介面執行安全任務。

5. 未來趨勢：零信任硬體架構

SPDM 是實現「零信任」硬體環境的基石，讓 BMC 能持續監控硬體狀態，一旦發現組件韌體異常或身分不明，可立即採取隔離措施。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Robot_Framework_打造_OpenBMC_測試食譜

海邊の蠑螈 — Tue, 07 Apr 2026 05:36:49 GMT

深入探討 Robot Framework 如何成為 OpenBMC 自動化測試的核心工具，並透過「測試食譜」的比喻，解釋其如何簡化複雜的伺服器測試流程。

以下為該錄音內容的重點整理：
1. Robot Framework 的核心優勢

關鍵字驅動 (Keyword-Driven)：Robot Framework 使用接近自然語言的關鍵字來撰寫測試案例，就像閱讀「食譜」一樣直觀，讓非軟體背景的硬體或測試工程師也能輕鬆上手。
高可讀性與維護性：測試腳本不再是晦澀的程式碼，而是具備邏輯的步驟描述，大幅降低了長期維護的門檻。
強大的擴充性：支援以 Python 撰寫自定義函式庫 (Library)，能與 OpenBMC 的各種介面（如 Redfish、IPMI、SSH）深度整合。

2. 打造 OpenBMC 的「測試食譜」
模組化設計：將常見的操作（如重啟 BMC、讀取感測器數值）封裝成可重複使用的關鍵字，這些就像是食譜中的「基礎醬汁」。
分層架構：

底層 (Library)：負責處理複雜的通訊協定（如 Redfish API）。
中層 (Resource)：將底層操作組合成具有業務意義的關鍵字。
頂層 (Test Case)：最終的測試案例，只需調用中層關鍵字即可完成測試。

3. OpenBMC 測試實務應用

跨介面驗證：同一個測試流程可以同時透過 Redfish 和 IPMI 進行驗證，確保不同管理介面的一致性。
自動化報告：Robot Framework 執行後會自動產生詳細的 HTML 報告與日誌，內含每個步驟的執行結果，方便工程師快速定位問題 (Debug)。
CI/CD 整合：這些測試腳本能輕易整合進 Jenkins 等開發流水線，實現持續集成與回歸測試。

4. 社群資源與開源貢獻

openbmc-test-automation：這是 OpenBMC 官方在 GitHub 上維護的測試專案，包含了上千個現成的 Robot 測試案例，開發者可以直接拿來當作「食譜參考」。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Redfish_讓硬體管理像呼叫_API

海邊の蠑螈 — Tue, 07 Apr 2026 04:00:19 GMT

深入探討 Redfish 協定如何取代傳統的 IPMI，成為現代資料中心硬體管理的標準，將伺服器維運轉向開發者友好的 RESTful API 模式。

以下為該錄音內容的重點整理與逐字稿摘要：
1. 技術轉型：從 IPMI 到 Redfish

IPMI 的侷限：傳統 IPMI 採用二進位格式，對開發者不直觀且擴充性差，難以應對現代大規模雲端架構。
Redfish 的優勢：基於 HTTP/HTTPS、JSON 格式與 RESTful 架構，讓硬體管理就像呼叫網頁 API 一樣簡單。

2. 核心架構設計

資源導向：所有硬體組件（如 CPU、風扇、電源）都被視為「資源」，擁有唯一的 URL 路徑。
標準操作：使用標準的 HTTP 動詞，例如 GET 讀取狀態、PATCH 修改設定、POST 執行重啟等動作。

3. Schema 與資料一致性

定義嚴謹：Redfish 定義了嚴格的 Schema，確保不同廠家的硬體在資料格式上具備一致性，降低自動化開發的門檻。

4. 擴展性與安全性

可擴展性：支援透過「OEM 擴充」自定義特殊功能，同時保持標準功能的相容性。
安全性強化：原生支援 HTTPS 加密與現代認證機制（如 Session-based 認證），比 IPMI 更符合現代資安規範。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

PLDM_終結_IPMI_硬體管理惡夢

海邊の蠑螈 — Tue, 07 Apr 2026 03:53:13 GMT

深入探討了伺服器硬體管理協定從傳統的 IPMI 轉向現代化 PLDM (Platform Level Data Model) 的技術變革，並分析了 PLDM 如何解決過往硬體監控的痛點。

以下為該內容的重點整理：
1. IPMI 的歷史地位與侷限性

硬體管理的先驅：IPMI 在過去 20 年是伺服器監控（如電壓、溫度、風扇轉速）的標準協定。
效能瓶頸：IPMI 的設計較為老舊，資料傳輸速度慢，且缺乏結構化的資料模型。
擴充困難：面對現代伺服器動輒數百個感測器的需求，IPMI 在定義與傳輸上顯得力不從心。

2. PLDM 的崛起與優勢

輕量化與結構化：PLDM 採用二進位格式傳輸，設計精簡，能有效節省頻寬與運算資源。
模組化架構：PLDM 包含多個子規範，例如：
PLDM for Monitoring and Control：負責感測器數據的讀取與控制。
PLDM for FRU Data：處理硬體資產資訊（如序號、型號）。
PLDM for Firmware Update：定義了標準化的韌體更新流程。
與 MCTP 協同工作：PLDM 通常承載於 MCTP (Management Component Transport Protocol) 之上，支援 I2C、PCIe 等多種傳輸介面。

3. PDR (Platform Descriptor Records) 的關鍵作用

自我描述機制：PDR 是 PLDM 的靈魂，它讓裝置能主動告訴 BMC（基板管理控制器）自己擁有多少感測器及其規格。
動態發現：BMC 不再需要硬編碼感測器資訊，只要讀取 PDR 就能自動識別硬體變更，實現真正的「插即用」管理。

4. 對伺服器產業的影響

簡化開發流程：硬體供應商只要遵循 PLDM 規範，其組件就能輕易整合進不同品牌的伺服器系統中。
提升系統維運效率：標準化的監控與更新機制，降低了資料中心管理的複雜度與出錯率。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_棄_Angular_選_Vue_的關鍵

海邊の蠑螈 — Tue, 07 Apr 2026 03:46:59 GMT

深入探討 OpenBMC 在 Web UI 開發上，為何從 AngularJS 轉向 Vue.js 的技術決策過程，並分析了開發社群在面對前端技術更迭時的權衡與考量。

以下為該錄音內容的重點整理：
1. 轉型背景：AngularJS 的終結

技術斷層：AngularJS（1.x 版本）即將進入生命週期終點（EOL），且與後續的 Angular（2+ 版本）架構完全不相容，導致社群必須重新選擇框架。
既有痛點：原有的 AngularJS 代碼庫變得臃腫且難以維護，這成為了推動技術換代的契機。

2. 選擇 Vue.js 的關鍵原因

學習曲線平緩：Vue 的設計哲學與傳統 HTML/JS 較為接近，對於以韌體工程師（C/C++ 背景）為主的 OpenBMC 社群來說，上手難度遠低於 TypeScript 門檻較高的 Angular。
輕量與靈活：Vue 提供的漸進式架構允許開發者根據需求引入功能，非常適合嵌入式系統（如 BMC）中相對輕量但功能密集的 Web 介面。
效能表現：Vue 的虛擬 DOM 機制與響應式系統，能更流暢地處理 BMC 監控數據的即時更新。

3. 開發實務與社群影響

前端與後端分離：透過 Redfish API 實現純粹的前後端分離，使得 Web UI 的開發可以獨立於底層韌體邏輯之外。
社群共識：這一轉變不僅是技術考量，更是為了吸引更多前端開發者參與開源貢獻，提升 OpenBMC 的使用者體驗。

4. 逐字稿內容摘要

開場：討論前端框架的「戰國時代」以及 OpenBMC 面臨的抉擇。
核心討論：對比 Angular 的嚴謹規範與 Vue 的靈巧自由，並提到為何 Vue 更符合韌體工程師的思維模式。
結論：轉向 Vue 之後，OpenBMC Web UI 的開發速度與模組化程度均有顯著提升。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_密碼為何限長_20_字

海邊の蠑螈 — Tue, 07 Apr 2026 03:43:00 GMT

解釋 OpenBMC 在使用者管理上的底層邏輯，特別是針對「密碼長度限制」與「權限解耦」的技術妥協。

以下為該文件的重點整理：
1. 核心設計原則：驗證與介面解耦

徹底解耦：OpenBMC 將介面（如 Redfish, IPMI, WebUI）與使用者管理核心完全分離。
統一樞紐：引入 phosphor-user-manager 作為中立的守門員，所有應用程式必須透過內部通訊匯流排（D-Bus API）查詢使用者資訊，確保未來擴充性（例如汰換 IPMI 也不會導致系統崩潰）。

2. 安全性保障：避免密碼裸奔

不傳遞密碼：為了防止密碼在系統日誌（Log）中洩露，D-Bus 不處理密碼驗證。
PAM 模組堆疊：採用 Linux 的 PAM (Pluggable Authentication Modules) 機制，在封閉的黑盒子中進行雜湊比對（使用 SHA-512）。

3. 技術衝突：為何密碼限長 20 字？

歷史遺毒：傳統的 IPMI RMCP+ 規範在底層運算時需要「明文密碼」。
被迫妥協：OpenBMC 為了相容 IPMI，當使用者屬於 IPMI 群組時，系統會額外儲存一份經 AES-128 加密的密碼版本。
硬性限制：由於 IPMI 早期記憶體與風包結構限制，AES 加密實作被鎖死在 20 個字元。若要使用超長密碼，唯一的解決辦法是將該使用者移出 IPMI 群組。

4. 企業部署實務

LDAP/AD 整合：大型企業常用遠端驗證。透過修改 common-auth 將 pam_ldap 順序移前，可加速登入。
Sufficient 標籤：設定 LDAP 為 sufficient，確保網路斷線時，系統仍會回頭檢查本地帳號，避免管理者被鎖在門外。
加鹽（Salt）的重要性：設定檔中必須存入帶有隨機延值的雜湊值（以 $6$ 開頭），以防範彩虹表攻擊。

5. 資安風險提示

Root 帳號風險：為了防止攻擊者鎖定管理權限，系統預設「不鎖定」Root 帳號，這使其面臨暴力破解風險。最佳實踐是停用 Root 的外部登入權限。
微型權限思維：目前許多內部程序仍以 Root 權限執行，未來架構應朝向權限切割發展。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_高效自動化開發流水線

海邊の蠑螈 — Tue, 07 Apr 2026 03:36:25 GMT

探討 OpenBMC（開源基板管理控制器）如何透過自動化流程，在包含超過 100 個程式庫（Repo）的超大規模開發環境中，確保系統的穩定性與開發效率。

以下是針對 OpenBMC 高效自動化開發流水線的關鍵架構與工具整理：
1. OpenBMC 的軟體架構層次
OpenBMC 的佈局分為三個主要層次，確保了硬體相容性與軟體靈活性：

應用程式層：包含大量 C++ 程式碼、網頁伺服器與狀態管理等核心功能。
中介資料層：存放針對不同硬體（如 IBM、Aspeed）設計的 BitBake 建置腳本，負責指導如何打包組件。
整合層：核心程式庫，將所有中介層與外部依賴（如 Yocto 底層系統）通整，產出最終的快閃記憶體映像檔。

2. 自動化開發與測試流程
系統建立了一套嚴謹的自動化機制，從程式碼提交到最終驗證：

程式碼審查與初步測試：開發者將程式碼推送到 Gerrit 平台後，系統會立即在 Docker 容器中執行編譯與 Google Test (GTest) 單元測試。
Auto-bump 腳本（自動推進機制）：這是一個每 5 分鐘執行一次的背景任務，它會巡視應用程式層，一旦發現審查通過的新程式碼，便會自動產生 Commit 並更新到中介層。
QEMU 模擬器驗證：在整合層階段，系統利用 BitBake 編譯出完整的映像檔，並在 QEMU 模擬器中進行「嗅覺測試 (Sniff Test)」，驗證虛擬 BMC 機器是否能正常開機、啟動網頁伺服器及回應 REST API。

3. 資源優化與開發者工具
由於 BitBake 編譯極度耗費資源（至少需 16GB 記憶體與 8 核 CPU），維護團隊採取了以下優化策略：

批次處理與流量管制：建議開發者將多個修改合併提交，並利用下班後的尖峰離峰時段進行手動合併，以減輕 CI 伺服器的負擔。
SState 快取機制：在本地編譯時，系統會利用半成品倉庫（SState），避免重複編譯未變動的部分，使編譯時間從 1 小時大幅縮短至 10 分鐘。
地端工具 run-unit-test-docker.sh：提供開發者在個人電腦上建立模擬無塵室環境，透過參數 --test-only 快速驗證邏輯，無需等待遠端 Jenkins 伺服器排隊。

4. 維護與貢獻門檻

程式碼覆蓋率分析：Jenkins 會定期掃描，產出 results.txt 與視覺化報表，協助團隊判斷哪些部分的測試保護不足。
新手注意事項：新貢獻者必須先簽署 CLA（貢獻者許可協議）並加入 Gerrit 白名單，CI 系統才會為其消耗伺服器算力。
溝通管道：遇到複雜的底層依賴問題時，建議直接進入 IRC 聊天室尋求各硬體廠商維護者的即時協助。

OpenBMC 透過這套自動化流水線，成功將全球多家企業的貢獻整合在一起，並在複雜的硬體環境中維持高度的系統信任與可靠性。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_的_IPMI_底層實作機制

海邊の蠑螈 — Tue, 07 Apr 2026 03:08:03 GMT

介紹 IPMI (Intelligent Platform Management Interface) 子系統在 OpenBMC 中的基礎架構與核心實作機制。
以下是這篇內容的核心重點摘要：

IPMI 與 BMC 的基本概念：IPMI 是一套用於遠端管理伺服器的標準介面，主要目標是降低管理的總體擁有成本 (TCO)。其核心是底板管理控制器 (BMC)，這是一個獨立的微控制器，即使主機處於關機狀態也能持續運作，負責監控系統感測器、控制電源操作以及記錄系統事件等。
OpenBMC 中的 IPMI 核心服務：在 OpenBMC 中，負責處理 IPMI 請求的核心守護行程是 phosphor-host-ipmid。該服務會接收來自不同介面通道（如本地端的 KCS 或遠端的 LAN）的訊息，解析其中的「網路函數 (NetFn)」與「指令編號 (Command)」來決定對應的動作。
與 D-Bus 系統的橋接運作：IPMI 子系統在 OpenBMC 中主要扮演「橋樑」的角色。當接收到 IPMI 指令時，ipmid 的處理常式 (Handlers) 會將這些請求轉換為對 OpenBMC 內部其他 D-Bus 服務的呼叫。例如，電源控制指令會去呼叫狀態管理服務 (State Manager)，而帳號密碼操作則會去呼叫使用者管理服務 (User Manager)。
通道設定與安全過濾機制：為了確保系統安全，OpenBMC 支援針對不同通道進行獨立設定。它實作了指令白名單與黑名單機制，管理員可以設定過濾規則，限制特定指令在特定通道上的執行權限（例如禁止透過外部 LAN 通道執行某些具風險的內部測試指令）。
非同步的指令處理架構：為了提升效能，現代的 OpenBMC IPMI 實作導入了非同步執行的機制（透過 C++ 的 yield_context）。這種設計確保了當某個 IPMI 指令需要較長時間等待 D-Bus 回應時，不會阻塞 (Block) 整個 IPMI 服務，讓系統能同時並行處理其他進來的 IPMI 請求。
指令註冊與優先權覆寫：開發者可以透過 ipmi::registerHandler() 函數輕鬆註冊新的 IPMI 指令，並指定其所需的最低權限等級。此外，系統支援依據優先權 (Priority) 來註冊指令，這讓硬體製造商能實作 OEM 專屬的處理常式來覆寫預設的標準指令行為。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_伺服器電源啟動與狀態管理

海邊の蠑螈 — Sun, 05 Apr 2026 17:25:26 GMT

介紹 systemd 與 Phosphor State Manager (PSM) 在 OpenBMC 中如何協同運作，以管理系統的各種狀態。
以下是這篇內容的核心重點摘要：

systemd 的核心概念：OpenBMC 大量依賴 systemd 來啟動與同步使用者空間的服務。理解其架構的兩個關鍵是 「服務 (Services)」（負責啟動應用程式）與 「目標 (Targets)」（將多個需要共同完成某個目標的服務群組化，例如啟動網路）。系統中也運用了「樣板 (Templating)」來讓服務與目標可以支援多個實例（例如多節點機殼）。
Phosphor State Manager (PSM) 的角色：PSM 相當於 systemd 的一層封裝 (Wrapper)，專門提供 OpenBMC 專用的標準化系統目標與服務，用以控制 BMC 本身、機殼 (Chassis) 以及主機 (Host) 的開關機狀態。
兩種 Target (目標) 的設計模式：
動作目標 (Action Targets)：將實際執行操作的一系列服務打包在一起，例如 obmc-chassis-poweron (開啟機殼電源) 或 obmc-host-start (啟動主機)。
同步目標 (Synchronization Targets)：這類目標本身不啟動任何服務，而是作為「執行順序的同步檢查點」。例如在真正開啟電源前，會有一個 start pre 的目標，確保所有前置準備工作（如電壓調整）都已完成，才會繼續執行後續動作。
動態的狀態發現與重置處理：如果 BMC 突然重新開機，PSM 不會依賴寫死的狀態，而是設計為去 「主動發現 (Discover)」 真實的硬體狀態。例如，它會去讀取 PGOOD GPIO 來確認電源是否已經開啟，或透過 D-Bus 查詢主機韌體是否正在運行。若確認設備已在運行中，PSM 會在檔案系統中建立一個特定的旗標檔案，這會讓 systemd 的服務在執行前透過條件判斷 (ConditionPathExists) 略過重複的開機操作，避免引發系統問題。
錯誤處理與靜止狀態 (Quiesce State)：如果 OpenBMC 內的關鍵服務或是主機啟動失敗，且超過了允許的重試次數，PSM 會將系統轉移到所謂的**「靜止狀態 (Quiesce)」**。這表示系統處於未知的失敗狀態，並會藉此觸發錯誤日誌與系統傾印 (Dump) 以供除錯，管理員也可以透過 Redfish API 觀察到此異常狀態並採取行動。
與 D-Bus 及 Mapper 的整合：PSM 的許多服務（以 Shell 腳本實作）會透過 busctl 指令來操作 D-Bus。它利用了 OpenBMC 中的 mapper 服務去動態尋找「是誰提供了這個 D-Bus 介面」，確認目標存在後，才發送如「開啟電源」這類的指令。

總結來說，OpenBMC 結合了 systemd 強大的依賴關係管理以及自家的 PSM 狀態機機制，來確保硬體在各種情境下（如冷開機、BMC 重啟、服務崩潰）都能維持正確且安全的運作狀態。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_Redfish_事件驅動與遙測實務

海邊の蠑螈 — Sun, 05 Apr 2026 17:22:54 GMT

介紹 OpenBMC 中的 Redfish 事件日誌 (Event Logs)、遙測服務 (Telemetry Service) 以及核心的 事件服務 (Event Service) 架構與運作機制。
以下是這篇內容的核心重點摘要：

事件日誌與訊息註冊表 (Message Registries)：為了節省 BMC 有限的儲存空間並支援多國語言，Redfish 規範採用了「訊息註冊表」。系統不再記錄冗長的完整訊息，而是記錄一組 Message ID。只要知道該 ID，就能查詢到對應的事件類型、嚴重程度與建議動作。在 OpenBMC 中，應用程式會將帶有特定 Redfish Message ID 的日誌寫入 systemd journal，接著被 rsyslog 過濾出來，並永久儲存至 /var/log/redfish 中以防重開機後遺失。
遙測服務 (Telemetry Service)：這項服務負責監控感測器資料（如 CPU 功耗、溫度、風扇轉速等）。使用者可以自訂「指標報告定義 (Metric Report Definitions)」，設定系統要收集哪些感測器資料，以及收集的頻率（例如每 10 秒收集一次）並將其產生為報告。
事件服務 (Event Service) 解決了「拉取 (Pull)」的網路負擔：過去管理者若要監控資料中心內成千上萬台伺服器的狀態，必須不斷地向每一台 BMC 發送請求來「拉取」日誌，這會造成龐大的網路流量與資料處理負擔。事件服務導入了**「推播 (Push)」的訂閱機制**，只要使用者完成訂閱，當有特定事件發生或遙測報告生成時，BMC 就會自動將資料推播給管理者。
兩種事件訂閱模式：
Push Style (Redfish 事件類型)：管理者需提供一個外部網頁伺服器，當事件發生時，BMC 會以 HTTP POST 主動將資訊傳送過去。這種訂閱是持續性的 (Persistent)，即使 BMC 重開機也會保留。此外，它還支援重試機制，若管理者的伺服器暫時無回應，BMC 可以依設定的時間間隔與次數進行重傳。
SSE (Server-Sent Events)：使用者（例如透過網頁瀏覽器）發出 HTTP GET 請求並通過驗證後，會保持該連線處於開啟狀態來接收事件流。這屬於非持續性的連線，若 BMC 重開機或網路中斷，使用者就必須重新進行連線與驗證。
過濾器與未來發展：使用者在訂閱時可以設定多種過濾條件（例如只接收特定 ID 或是特定嚴重程度的事件）。講者也提到目前的 OpenBMC 尚未支援 Redfish 規範中的 SNMP Trap、SNMP Inform 以及 Syslog 訂閱類型，這將是未來開源社群可以貢獻開發的機會。此外，IBM 團隊也正致力於擴充更多的資源類型過濾功能。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

Entity_Manager_動態配置與快取地雷

海邊の蠑螈 — Sun, 05 Apr 2026 17:19:16 GMT

介紹 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 拓撲架構。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

AI_伺服器捨棄_IPMI_改採_PLDM

海邊の蠑螈 — Sun, 05 Apr 2026 16:15:39 GMT

介紹 OpenBMC 系統中的 PLDM (Platform Level Data Model) 軟體堆疊架構。以下是這篇內容的核心重點摘要：

推動 PLDM 的動機：過去的伺服器內部管理多半依賴傳統的 IPMI 規範，但為了解決其擴充性限制並支援業界標準硬體的互通性，目前正逐漸轉向更現代化的 PMCI (Platform Management Components Intercommunication) 協定，而 PLDM 即為其中的關鍵規範。
分層與傳輸架構：PLDM 採用分層架構，通常運行於 MCTP (管理元件傳輸協定) 之上。這種設計讓上層的 PLDM 協定能完全獨立於底層的實體傳輸介面（如 SMBus、PCIe），未來若有新的硬體介面也能輕鬆整合。
PLDM 的核心規範 (Types)：PLDM 不是單一標準，而是由多種針對不同功能的規範組合而成，包含：硬體監控與控制（感測器/狀態）、BIOS 設定、FRU 資料交換、韌體更新、以及 RDE（Redfish 裝置啟用，用以協助無網路堆疊的裝置支援 Redfish）等。
資料模型設計：
實體 (Entities)：系統中的元件皆被定義為實體（如物理機殼、風扇、邏輯電源供應器等）。
PDR (Platform Descriptor Records)：類似中介資料 (Metadata)，負責描述感測器的單位等詳細資訊，並用來建立系統內不同實體之間的層級關係。相較於 IPMI，PLDM 的編碼空間更大，能支援更多數量的感測器與元件。
OpenBMC 的實作元件：
libpldm：跨平台的 C 語言函式庫，主要負責 PLDM 訊息的編碼與解碼。
PLDM Responder & Daemon：負責接收與路由 PLDM 請求，這部分以現代 C++ 開發，並能透過 D-Bus 呼叫 OpenBMC 內部的其他應用程式。
pldmtool：這是一個命令列的請求者 (Requester) 工具，可用來向 BMC 本身或連接的裝置發送指令，方便進行測試。
未來發展：目前實作多集中於讓 BMC 作為「回應者 (Responder)」。未來的重點開發項目包含：讓 BMC 能更完善地作為「請求者」去主動向其他連線裝置（例如網卡）要資料，以及補齊 PLDM 韌體更新與 RDE 支援。

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn

OpenBMC_D-Bus_系統開發實務

海邊の蠑螈 — Sat, 04 Apr 2026 00:51:46 GMT

OpenBMC 架構中的核心通訊機制 D-Bus，並詳細探討兩個負責處理該機制的關鍵資料庫：sdbusplus 與 phosphor-dbus-interface。
以下是這篇內容的重點摘要：

D-Bus 在 OpenBMC 中的角色：OpenBMC 的架構是由許多小型處理程序 (Processes) 所組成，這些程序之間依賴 D-Bus 進行處理程序間通訊 (IPC)。D-Bus 是物件導向的，包含服務 (Services)、物件路徑 (Object paths)、介面 (Interfaces)、屬性 (Properties)、方法 (Methods) 與訊號 (Signals) 等核心概念。
sdbusplus** 函式庫**：這是 OpenBMC 為了操作 D-Bus 所開發的 *C++ 封裝庫*。它將底層的 C 語言 API (由 systemd 提供) 進行包裝，提供了現代 C++ 的優點，包含：自動資源管理 (RAII)、自動型別推導，以及將底層錯誤轉換為 C++ 例外處理 (Exceptions)。此外，它還包含了一個名為 sdbus++ 的 Python 工具，可以將 YAML 格式的介面定義檔，自動產生為 C++ 的標頭檔與伺服器端程式碼。
phosphor-dbus-interface** 資料庫：這是一個集中存放所有 OpenBMC 共用 D-Bus 介面定義 (YAML 格式)** 的存放庫。它的目的是定義出一套通用的軟體模型，讓不同功能的程式能依循共同的標準進行溝通與實作，並考量了未來硬體架構的擴充性 (例如多主機刀鋒伺服器或非傳統運算裝置)。
服務定位 (Mapper)：因為 D-Bus 上的物件可能是動態建立且具備不同的路徑，OpenBMC 開發了一支名為 mapper 的程式。它會在背景監聽 D-Bus 的訊號，紀錄所有物件的位置，並讓其他程式能快速查詢特定介面在哪裡。
未來的發展計畫：講者預告了未來的幾項更新，包含將 phosphor-dbus-interface 的建置系統轉換為 Meson，以及導入 C++20 的協程 (Coroutines) 功能，以更簡潔的語法來處理非同步的 D-Bus 操作，並預計以此為基礎開發新的客戶端綁定 (Client bindings)

--
Need your feed to make us stronger:
https://pay.soundon.fm/podcasts/5c5e10cb-126f-4afe-a649-33e43faa86a0
Let’s become OpenBMC Masters together!
--
Hosting provided by SoundOn