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 遵循 WebArch 的識別原則，也就是「全球命名可帶來全球性的網路效應」。因此，無論網址所在的背景為何，特定元件網址都會參照相同的邏輯實體。這種做法表示，Fuchsia 會有一套涵蓋所有產品和電路板設定的軟體。每個產品都能夠使用相同的網址參照核心領域，且該網址後方的內容因產品而異，這並未遵循這項原則。

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

所有產品都會顯示的元件會位於通用基礎，而系統只會為部分產品未包含的元件建立分片。如果新增產品想要排除先前所有產品都包含的某些元件，則系統會將該元件重構出常見的基礎，並納入分割區。

工作階段和產品專屬路徑

如果核心領域中的產品專屬功能必須透過工作階段管理員轉送至工作階段，則有兩種可能的做法。

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

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

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

實作

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

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

成效

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

安全性考量

這項提案會導致不應在產品上執行的元件，實際上並未在該產品上執行。這也能讓我們為元件提供所需的功能，讓元件能夠在執行的產品上運作，而非一律為元件提供跨產品所需的功能組合。

這項提案會導致 CFv2 領域結構的多種可能變化，導致安全性稽核和工具 (例如審查) 需要處理新機制，以及產品之間的共用基礎較少。

隱私權注意事項

這項提案會導致元件只存在於應執行的產品中，且不會收到過於廣泛的功能集，這兩者都有可能改善系統的隱私權保證。

測試

產品擁有者必須確保產品包含必要元件，且測試時會涵蓋這些元件。雖然這項情況已因產品專屬的套件組合而成真，但這裡提出的核心領域變化會增加另一個可能導致產品定義誤略重要元件的情況。這會導致產品擁有者負擔稍高的負擔，以確保測試設定與產品設定保持一致。

說明文件

產品擁有者可設定的確切 GN 引數，會在 GN 中定義的所在位置記錄下來。此外，我們也會維護 Markdown 說明文件，說明每個資訊清單區塊，以及這些區塊對產品核心領域的影響。