擴充產品組合和設定

專案主管：aaronwood@google.com Area(s)：Build, Developer

問題陳述

產品 5 必須先完成所有軟體的編譯步驟，然後再「樹狀結構內」完成這項操作。

我們一直在不斷增加產品設定，並支援多種維度 (_eng、_eng_arrested、_user、_userdebug、LSDi 等)，方便命名開發人員、測試人員和客戶所需的各項設定。

產品擁有者和開發人員仍無法輕易表達想在任何指定時間建構/執行的組合。

這些定義大多是由下列維度的組合展開所致：

  • 要運送的基本產品
  • 元件版本：穩定版、最新、開發人員
  • 產品類型：eng、eng_arrested、userdebug、user

透過使用對其他套件中的元件的明確套件網址，元件拓撲本身會在裝置的 fuchsia-pkg:// 命名空間中加密，因為每個套件的完整網址會直接列在父項的 Cml 中：

  • root.cml
  • core.cml

如要變更某些通訊協定實作時使用的套件元件，某些其他套件的內容必須改為參照該套件網址。

Fuchsia 開發人員和發布團隊必須在樹狀圖中管理我們合作夥伴的所有產品，而且樹狀產品擁有者無法按自身時間表發布或更新產品。這讓 Fauchsia 機構大幅增加負載，並為產品擁有者增添阻礙。

解決方案陳述式

為解決這個問題，我們提議建立一組可執行樹狀結構外結構的工具，將組合與設定的概念結合為相同程序的各個部分：

  • 組合是指指定以下程序：

    • 要使用哪些軟體元件
    • 為何 API 對彼此的影響 (單一元件的拓撲)
    • 該如何設定
    • 何時可以重新設定 (以及由誰)

  • 是下列項目：

    • 確保每個元件都能正確運作
    • 產品的 CFv1 sysmgr 設定
    • 產品的整體 CFv2 拓撲
    • 核心啟動引數

上述程序都是相同程序的兩個主軸：如何針對特定產品組合及設定 Fuchsia。

為了進一步控管 Fuchsia 的使用和設定，我們提議導入「副組件」的概念。每個子組合會定義一組位於拓撲中、設定點和值的軟體和檔案，並提供明確的說明文件，說明在組譯過程中可以修改哪些設定。

完成後：

  • Fuchsia Platform 定義了子組件，讓產品可以在執行這個樹狀結構外組件時，選擇要組合的平台行為。
    • 其中一個例子就是包含 omaha-client (使用者偵錯/使用者版本) 的軟體推送堆疊子組件，以及使用 system-update-checker (eng 建構) 的軟體推送堆疊。
  • 客戶產品可完全在樹狀結構外組合，不必直接使用 fuchsia.git
  • 多個產品子類可以從同一組已編譯的軟體元件組合在一起。

依附元件

遷移客戶產品以使用子組件。這需要與 yaar@ 及其他相關人員討論，確保我們是否已妥善擷取他們的正確面向。

遷移 Fuchsia 平台以使用子組件。這需要與各個子系統團隊討論，以確保取得適當的變化版本。

如要建立樹狀結構外映像檔，特定工具 (fvm、blobfs、minfs、zbi、avbtool) 必須轉換為可使用樹狀結構外模式 (用於連結 Rust 的靜態程式庫，或完全轉移至 Rust 的靜態程式庫)。

風險與緩解措施

主要風險如下：

  • 新工具產生的輸出內容不會與現有工具相同

    • 緩解：在 CI/CQ 中同時執行這兩個 API，驗證新工具會產生相同的輸出內容，然後改用新的工具。

  • 樹層級和樹系工具的功能可能不同

    • 緩解：使用物外工具做為樹狀結構內工具，這樣我們不提供兩種需要維護的工具。

  • 以子組件架構設計可用於尋找完美的架構。

    • 緩解：所有結構定義都將以明確意圖為前提，在過程中加以修改，而重點放在務實的解決方案，而不是建立完美的系統模型。

  • 大規模遷移 (產品和平台)

    • 緩解：可以分階段完成，首先可從元件/標籤組合開始，到完全定義的子組合。
    • 緩解措施：實作計畫是以實際測量方法為中心，不會凝聚海洋。