| RFC-0089：核心領域變化版本 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 產生每個產品設定的自訂核心元件運作範圍。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-03-04 |
| 審查日期 (年-月-日) | 2021-04-19 |
摘要
產品定義中設定的 GN 變數可用來產生自訂核心領域 加入該產品元件架構中
提振精神
目前元件架構的 CFv2 核心領域是 包含第 2 版系統中大多數其他的封裝元件。系統提供單一版本 讓每項產品 這些元件適用的 v2 元件和能力路徑這會導致 不具用途、永遠不會執行且過於廣泛的現有元件 由於核心領域必須建立 是所有產品設定的聯集。
此外，v1 元件架構在建構時有條件支援
為特定產品的 sys 領域新增功能和元件。阿斯
元件會從第 1 版遷移至第 2 版，而元件原本依附
會使現有模型的問題更加複雜
需要一個符合每項產品要求的單一定義
一起使用
部分元件已從 v1 sys 領域遷移至 v2
core領域，預計第二波的遷移速度預計會增加
2021 年第四季
基於上述原因，我們需要能夠 CFv2 領域的中心結構，以配合執行產品的產品。
範圍
這項設計旨在在短時間內，解鎖其他元件遷移作業 。這項設計並非 這款應用程式適合用樹種的產品， 合適的長期解決方案PDK 工作 (目的是讓企業在樹上工作) 有助於更全面地解決上述問題 。
設計
核心領域資訊清單的內容會分為一組共通性
包含元件的 CML 資料分割，以及其能力路徑
每項產品可視需要加入例如：/core/temperature-logger
目前 CFv2 中的元件，只能在 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。
這是因為元件是透過網址識別。這些識別碼 網路世界的識別原則：「全域命名可讓全球 網路效果」。因此，指定的元件網址會參照相同的邏輯 實體。這個做法代表 Fuchsia 有一款軟體時，它涵蓋所有產品 設定。讓每項產品都能使用相同網址 到核心領域，而該網址背後的內容因產品而異 不會遵循這項原則
由於產品之間的核心領域網址現在不同， 根元件資訊清單會在建構期間修改，加入 目前產品的核心領域這個產品專屬的根領域範圍 不需要以核心領域等不同方式包裝 直接納入 .BI 中，這是已產生的產品專用。
出現在所有產品的所有元件也須位於通用基礎中 系統只會為部分未包含的元件建立資料分割 很少直接解答該如何打造產品如果新增產品且想要排除 直到先前所有的產品都納入該時間點為止 會從一般底數重構為資料分割
工作階段和產品專屬路徑
核心領域中的產品專屬功能 透過工作階段管理員轉送到這個工作階段，有以下兩個可能的選項。
第一個方式是讓工作階段管理員轉送所有功能的超集 在此情況下，轉送無法使用的功能 也會失敗
第二種做法是使用資料分割方法 產品專屬工作階段管理員資訊清單，這與本提案內容相同 概述如何為核心領域完成這項作業在這種情況下，轉送到 無法使用的功能將無法在工作階段管理員領域執行這個方法 必須同步工作階段管理員和核心資料分割清單。 也會增加建構複雜度和維護成本
這兩個選項在 會很有幫助
實作
這項變更可在單一國家 CL 中完成。GN 引數預設為 產品定義可以新增覆寫值，以便啟用想要的功能 我們稍後會確認
未完成但可正常運作的實作，示範這個方法的做法 請參閱這裡。
成效
此提案中的所有工作都是在建構階段進行，因此 執行階段效能影響
安全性考量
本提案將導致的元件不應在不合適的產品上執行 現有 YAML 產品這也能使我們得以提供元件 提供執行產品所需的功能 一律提供元件所需的功能聯集 很少直接解答該如何打造產品
這項提案會產生多個 CFv2 領域可能的變化版本 並導致安全性稽核與工具 (例如審查作業) 需要能夠處理新機制，同時減少共用基礎資源 也不必在不同產品之間取得平衡
隱私權注意事項
本提案只會將所含組件僅存於符合以下條件的產品上 應該不會產生過於廣泛的功能 有機會改善系統的隱私權保證。
測試
產品擁有者必須確保 以及這些元件的呈現在測試範圍 雖然因產品專屬的套件集的關係而已，但核心領域 這裡建議的變化版本，在 可能會不小心省略重要元件這會產生 減輕產品擁有者負擔，以確保能繼續測試設定 確保產品設定一致
說明文件
產品擁有者可以設定的確切 GN 引數會在此處記錄在 也就是 GN 中定義的位置Markdown 說明文件將成為 說明每個資訊清單資料分割以及其對 針對產品的核心領域