| RFC-0089：核心領域變化 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 根據產品設定產生自訂核心元件運作範圍。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2021-03-04 |
| 審查日期 (年/月) | 2021-04-19 |
摘要
產品定義中設定的 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 遵循網路架構原則來識別，「全域命名會引發全域網路影響」。因此，無論網址存在的內容為何，特定元件網址都會參照相同的邏輯實體。這種方法意味著，Fusia 有一套軟體跨越所有產品和主面板設定。如果讓每項產品都能夠使用同一個網址代表核心領域，且網址後方的內容會因產品而異，就不適用這個原則。
由於核心領域的網址現在在不同產品間都不同，因此系統會在建構期間修改根元件資訊清單，以納入目前產品的核心運作範圍的正確網址。這個產品專屬的根領域不需要以不同方式封裝，例如核心領域，因為 ZBI 會直接包含在特定產品的 ZBI 中。
所有產品中顯示的所有元件都會位於共同基礎中，且只會為不包含在部分產品中的元件建立資料分割。如果新增的某項產品，希望從所有舊有產品都納入該點之前，想要排除某些元件，這個元件就會從共同基礎重構並轉換為資料分割。
工作階段和產品專屬路徑
當核心領域中的產品專屬功能須透過工作階段管理員轉送至工作階段時，有兩種可能的選項。
例如讓工作階段管理員轉送所有產品的所有功能超集。在此情況下，無法使用功能的轉送會在核心領域失敗。
第二種方式是使用資料分割的方法同時建構產品專屬的工作階段管理員資訊清單，這和本提案概述了為核心領域進行的方式相同。在此情況下，無法使用的功能轉送會在工作階段管理員領域失敗。此方法需要工作階段管理員和核心資料分割清單保持同步，並增加建構複雜度和維護成本。
就工作階段的角度來看，這兩種選項看起來都相同。
實作
這項變更可以透過單一生化 CL 進行。由於 GN 引數具有預設值，產品定義可新增覆寫，以便日後啟用所需功能。
有些實作還未完成，展示了這個方法的運作方式，請參閱這裡。
效能
由於本提案的所有工作都是在建構時間進行，因此不會對執行階段的效能產生任何影響。
安全性考量
本提案將產生的元件不應在現有產品上運作。透過這個 API，我們也能為執行這些產品的產品提供所需功能，而不是一律為各產品提供所需功能聯集。
本提案會導致 CFv2 運作範圍有多種可能的變化版本，導致安全性稽核與工具 (例如審查) 必須能夠處理新機制和產品之間的共用基底。
隱私權注意事項
本提案將只會讓現有元件在應該執行的產品上運作，且不會取得過於廣泛的功能，這兩者都有可能改善系統的隱私權保證。
測試
產品擁有者必須確保產品中包含必要元件，且測試期間是否涵蓋這些元件。雖然因產品專屬的套件組合而也是如此，但在這裡提議的核心領域變化版本，又加入另一個可能讓產品定義意外省略重要元件的時間點。這會導致產品擁有者負擔略高的負擔，可確保測試設定與產品設定保持一致。
說明文件
系統會將產品擁有者可設定的確切 GN 引數記錄在 GN 中定義的位置。此外，Markdown 文件將維護各項資訊清單資料分割的說明，以及其對產品核心領域的影響。