RFC-0089：核心運作範圍變化

摘要

產品定義中設定的 GN 變數，可用於在該產品的元件架構中產生自訂核心領域。

提振精神

在元件架構的 CFv2 中，核心領域是元件，可保存 v2 系統中的大多數其他封裝元件。這個元件只有一個版本，因此每個產品都有一組相同的靜態 v2 元件，以及這些元件的能力路徑。這會導致兩個元件存在，但沒有任何用途，且永遠不會執行，並為元件提供過於廣泛的功能，因為核心領域必須建構為所有產品設定的聯集。

此外，v1 元件架構支援在建構時，有條件地將功能和元件新增至特定產品的 sys 領域。由於元件會從 v1 遷移至 v2，因此已依附於此的元件會進一步加劇目前模型的問題，導致核心領域需要單一定義，才能同時滿足每個產品的需求。

部分元件已從 v1 sys 領域遷移至 v2 core 領域，預計 2021 年第二季的遷移速度會加快。

因此，我們需要能夠調整 CFv2 領域中央結構的確切內容，以配合執行的產品。

範圍

這項設計的目標是在更先進的解決方案推出前，於短期內解鎖其他元件遷移作業。這項設計不適用於樹狀結構外的產品，也不是長期的解決方案。PDK 的目標是啟用樹狀結構外的產品組裝，以更全面的方式解決這裡提到的問題。

設計

核心領域資訊清單的內容會分成通用基礎和 CML 分片，其中包含元件和元件的能力路徑，產品可選擇性納入這些內容。舉例來說，CFv2 目前提供的 /core/temperature-logger 元件只能在 astro 產品上運作。與其在基本核心資訊清單中加入與 temperature-logger 相關的項目，不如在個別檔案中加入下列分片：

{
    children: [
        {
            name: "temperature-logger",
            url: "fuchsia-pkg://fuchsia.com/temperature-logger#meta/temperature-logger.cm",
        },
    ],
    offer: [
        {
            protocol: "fuchsia.thermal.test.TemperatureLogger",
            from: "#temperature-logger",
            to: [ "#appmgr" ],
        },
        {
            protocol: [ "fuchsia.logger.LogSink" ],
            from: "parent",
            to: [ "#temperature-logger" ],
        },
        {
            directory: "dev-class",
            as: "dev-temperature",
            from: "parent",
            to: [ "#temperature-logger" ],
            subdir: "temperature",
        },
        {
            directory: "dev-class",
            as: "dev-thermal",
            from: "parent",
            to: [ "#temperature-logger" ],
            subdir: "thermal",
        },
        {
            directory: "config-data",
            from: "parent",
            to: [ "#temperature-logger" ],
            subdir: "temperature-logger",
        },
        {
            protocol: [
                "fuchsia.device.Controller",
                "fuchsia.hardware.temperature.Device",
            ],
            from: "parent",
            to: [ "#temperature-logger" ],
        },
        {
            protocol: "fuchsia.tracing.provider.Registry",
            from: "#appmgr",
            to: [ "#temperature-logger" ],
            dependency: "weak_for_migration",
        },
    ],
}

這個分片會使用 GN 範本為自己建立目標，其中包含分片的路徑。以 temperature-logger 範例來說，目標會如下所示：

core_shard("temperature_logger_shard") {
  shard = "//meta/temperature-logger.shard.cml"
}

每個產品的 .gni 檔案 (例如 //products/workstation.gni) 都能指定要納入產品核心領域的碎片 GN 目標。

core_realm_shards += [
  "//src/sys/core:temperature_logger_shard"
]

在產品組裝時，這些目標會使用 GN 的generated_file()目標收集，並做為 CMC 合併作業的輸入內容，其中要納入產品的碎片會與核心領域的基準碎片合併。在目前的範例中，只有 temperature-logger 的分片會與核心基本分片合併。

這個產生的核心領域會納入套件中，套件名稱則衍生自產品。舉例來說，工作站產品的核心資訊清單會封裝在 fuchsia-pkg://fuchsia.com/core-workstation#meta/core.cm。

這是因為元件是透過網址識別。這些 ID 遵循網頁架構的識別原則，也就是「全球命名可帶來全球網路效應」。因此，無論元件網址所在的環境為何，都會參照相同的邏輯實體。這種做法表示 Fuchsia 有一個軟體宇宙，涵蓋所有產品和主機板設定。如果每個產品都能使用相同的網址參照核心領域，且該網址後方的內容會因產品而異，就不符合這項原則。

由於核心領域的網址現在會因產品而異，因此系統會在建構時修改根元件資訊清單，以納入目前產品核心領域的正確網址。這個產品專屬的根領域不需要像核心領域一樣以不同方式封裝，因為它會直接納入 ZBI，而 ZBI 本身就是產品專屬。

所有產品都有的元件會位於通用基底中，而系統只會為部分產品未納入的元件建立分片。如果新增的產品要排除某個元件，但該元件先前已納入所有產品，則系統會將該元件從通用基礎重構至分片。

工作階段和產品專屬路徑

如果核心領域的產品專屬功能要透過工作階段管理工具傳送至工作階段，有兩種可能選項。

其中一種做法是讓工作階段管理員在所有產品中，將所有功能的超集路由傳送至在這種情況下，無法使用的功能會導致核心領域的路由失敗。

第二個選項是使用分片方法，建構產品專屬的會期管理員資訊清單，做法與本提案中針對核心領域的說明相同。在這種情況下，無法使用的功能會在工作階段管理員領域中路由失敗。這種做法需要讓工作階段管理員和核心分片清單保持同步，並增加額外的建構複雜度和維護成本。

從工作階段的角度來看，這兩個選項看起來完全相同。

實作

這項變更可以在單一 gerrit CL 中完成。由於 GN 引數具有預設值，產品定義可以新增覆寫，以便稍後啟用所需功能。

如要查看不完整但可運作的實作方式，瞭解這種做法的運作方式，請按這裡。

效能

由於本提案中的所有工作都是在建構階段進行，因此不會對執行階段效能造成任何影響。

安全性考量

這項提案會導致不應在產品上執行的元件，在該產品上執行。此外，我們也能為元件提供在產品上執行時所需的功能，而不是一律提供元件可能在各產品中需要的功能聯集。

這項提案會導致 CFv2 領域結構出現多種可能的變化，因此安全稽核和工具 (例如 scrutiny) 必須能夠處理新機制，且產品間的共用基礎也會減少。

隱私權注意事項

這項提案可確保元件只存在於應執行的產品上，且絕不會收到過於廣泛的功能集，這兩者都有可能提升系統的隱私權保障。

測試

產品負責人必須確保產品包含必要元件，且測試涵蓋這些元件。雖然這項提案已因產品專屬的套件組而成立，但這裡建議的核心領域變體會新增一個點，產品定義可能會意外省略重要元件。因此，產品負責人必須確保測試設定與產品設定保持一致，負擔稍重。

說明文件

產品擁有者可設定的確切 GN 引數，將記錄在 GN 中定義的位置。此外，系統會維護 Markdown 說明文件，說明每個資訊清單分片，以及對產品核心領域的影響。