本頁面由 Cloud Translation API 翻譯而成。

RFC-0182：淘汰 config-data

RFC-0182：淘汰 config-data
狀態	已接受
區域	元件架構
說明	意圖淘汰舊機制，以便在各存放區的元件之間提供/使用設定檔
問題	101976
Gerrit 變更	696482
作者	shayba@google.com
審查人員	aaronwood@google.com adamperry@google.com ampearce@google.com awolter@google.com ddorwin@google.com fmil@google.com geb@google.com jsankey@google.com kpozin@google.com wez@google.com yaar@google.com ypomortsev@google.com
提交日期 (年-月-日)	2022-06-30
審查日期 (年-月-日)	2022-08-15

編輯此 RFC

編輯 RFC 中繼資料

摘要

本 RFC 建議：

宣告 [config-data] 機制已淘汰。
為現有用途建立許可清單。
隨著時間推移，將現有的 config-data 用法替換為其他更優質的解決方案。
最終從 Fuchsia 中移除對 config-data 的支援。

提振精神

這份 RFC 的當前目標，是建立大致的共識，為現有的 config-data 用法建立許可清單，並偏好不擴充該許可清單。我們會提供與這項立即目標無關的其他資訊，以提供額外背景資訊，並滿足各方利益相關者的請求。

[config-data] 是設定檔的機制，可在執行階段提供該元件命名空間中的特定檔案，藉此調節已封裝元件的行為。

config-data 會使用未強制執行的契約或慣例，針對目標元件的套件名稱建立「遠端詭異動作」。這會造成問題，因為套件名稱無法做為穩定的 ID，無法成為 Fuchsia SDK 途徑的一部分、使用 SDK 進行版本控制，以及隨著時間演進，例如宣告支援的視窗和允許軟性轉換。經驗證明，以套件名稱為基礎的契約會導致不穩定的執行階段假設，且維護成本高昂。

此外，由於 config-data 會將開發人員套件的內容與含有設定檔的基礎套件內容混合，因此會造成令人困惑的開發人員體驗，開發人員會推送套件的新修訂版本，但在執行階段看到舊設定檔。開發人員經常會詢問，為何他們推送套件的更新版本，但卻在 /config/data 下看到過時的檔案，而沒有意識到這些檔案來自不同的套件。向開發人員說明這項行為時，必須向他們揭露平台實作細節，例如「基本套件」，這表示抽象化失敗，因此不建議這麼做。更不用說，這類週期性工作流程的不一致性會導致工作效率下降。

config-data 非常適合解決以下問題：在產品組裝的不同階段，參與者需要影響不受直接控管的元件。使用 config-data 時，來自某個位置 (存放區、建構系統等) 的設定值可用於調節來自其他位置的元件行為。

在某些情況下，元件和設定具有相同的來源，但使用者仍偏好使用 config-data 做為整合點。這可讓使用者產生一個套件，並將不同的設定值側載至此套件所包含的元件。當產生多個套件的成本很高時，這項功能就很實用，例如每個套件版本都需要個別上傳至後續整合點。

目前有許多 config-data 的替代方案。這些方法包括根據目錄功能、結構化設定、透過通訊協定功能提供設定，以及封裝設定檔與使用這些檔案的元件，來轉送設定目錄。

雖然淘汰 config-data 的現有用途和功能本身並非當務之急，但我們應將新用途導向新式解決方案，並促使現有用途的擁有者遷移至新式替代方案。

在這種情況下，最佳做法是為 config_data() GN 規則建立許可清單，並使用現有的用法進行初始化。隨著時間推移，許可清單的項目數量預計會趨近於零，但如果目前的替代方案不適用，則可將新用途加入許可清單。當新的用途獲得核准，允許變更時，應事先說明原因，以減少程式碼審查的流失率。

背景

`config-data` 的運作方式

在舊版 appmgr (又稱為 CFv1) 中，config-data 是透過將已啟動的元件套件名稱與 config-data 基本套件中的子目錄進行比對來實作。如果找到相符項目，系統會在啟動的元件命名空間中，於路徑 /config/data 下提供相符的子目錄。

定義 config-data 的方式是指定要提供的檔案、在元件傳入命名空間中提供這些檔案的路徑 (依慣例，在 /config/data 下方)，以及一或多個元件的套件名稱，這些元件應在這些路徑中提供這些檔案。

舉例來說，元件可能會要求使用設定檔，如下所示：

{
    use: [
        {
            directory: "config-data",
            rights: [ "r*" ],
            path: "/config/data",
        },
    ],
}

這表示元件要求嵌入者提供名為「config-data」的唯讀目錄能力，該功能會在 /config/data 的架構中顯示，讓依賴 /config/data 的現有程式碼不必經過修改即可運作。

父項元件或領域可能會有以下宣告：

{
    children: [
        {
            name: "font-provider",
            url: "fuchsia-pkg://fuchsia.com/fonts#meta/font-provider.cm",
        },
    ],
    offer: [
        {
            directory: "config-data",
            from: "parent",
            to: [ "#font-provider" ],
            subdir: "fonts",
        },
    ],
}

這個方法會從父項接受包含多個子目錄的 config-data，並將包含字型提供者設定資料的 example 子目錄，轉送至該元件。

config-data 的內容可能來自以下建構定義：


import("//build/config.gni")

config_data("example_config_data") {
  for_pkg = "example"
  sources = [
    "file1.dat",
    "file2.dat",
    ...
  ]
  outputs = [ "{{source_file_part}}" ]
}

上方的目標和其他類似目標會由建構系統收集，以形成名為 config-data 的套件內容。接著，專門設計的路由規則會將 config-data 套件的所有內容，以上述 for_pkg 參數所示的子目錄形式，路由至核心領域和其他位置，並進一步將這些內容分派給會使用這些內容的各種元件。

`config-data` 目前的使用方式

config-data 具備多種用途。以下列舉幾個說明範例：

ICU 資料和 tzdata：ICU 程式庫的資料，特別是時區資料 (「tzdata」)，會在執行階段以 config-data 的形式提供。在 Fuchsia 平台來源中定義這些資料檔案的單一來源，並將檔案提供給來自不同來源 (例如 Chromium、Flutter、Google 內部存放區等) 的元件，以確保只使用這些檔案的單一修訂版本。這可達成一致性 (例如，所有元件都同意使用單一 tzdata，不論來源為何) 和效率 (所有元件都共用相同的 ICU 球狀結構，不論建構時間或地點為何)。
buildinfo 和 hwinfo 元件的值會以 config-data 的形式提供。這些元件是使用平台原始碼建構，但可能需要由產品設定。目前 config-data 是這項設定機制的服務。
在平台來源中定義的「設定」UI 元件，可設定為在不同裝置上公開不同的硬體切換按鈕。舉例來說，SetUI 在 Astro 和 Sherlock 裝置上的行為不同，目前由 config-data 管理。
平台字型供應器元件可設定為提供特定產品的字型。字型檔案和說明其屬性的資訊清單會以 config-data 的形式提供，並在樹狀結構外產品組合中新增。

設計與導入

我們會建立建構時間回歸停止功能，以免未經明確核准就使用 config-data。系統會檢查現有用法的許可清單，並由 OWNERS 檔案管理許可清單的變更。我們會指派元件架構團隊的擁有者，代表 fuchsia.git，以及使用 config-data 代表其用法的花瓣。代表將負責管理各自的許可清單項目，例如協助進行重構或指定燒毀作業。

實作回歸停止點的方式並不重要。常見且可能的實作策略是變更 config-data GN 範本，在目標上新增依附於設定的顯示清單。值得注意的是，這項功能只涵蓋樹狀結構內的用法，但限制樹狀結構外產品組合中 config-data 的新用法也相當重要。我們也可能會在這裡與 PDK 團隊合作，開發適當的機制。

深入探討 config-data 的替代方案不在本 RFC 的討論範圍內。參考這些替代方案時，請詳閱上方連結的說明文件。

建立提供元件設定的最佳做法，或為 config-data 以外的遷移指南提供種子，不在本 RFC 的討論範圍內。我們正在製作這類文件，並會與此 RFC 分開發布。

成效

config-data 套件的特殊且有趣之處在於，所有檔案都會封裝在 meta/ 路徑下。這表示檔案會封存至 meta.far 檔案。儲存在基礎 blobfs 檔案系統中時，磁碟上的檔案大小會四捨五入至區塊大小，通常為 8KiB。將設定檔一起封存後，便可省去捨入所產生的額外負擔。這點很重要，因為設定檔通常數量眾多且體積較小，因此總的額外負擔可能會大於這些檔案的壓縮大小總和。

使用其他解決方案時，如果儲存空間很重要，請使用相同或等同的技術，確保儲存空間效率一致。

人體工學

config-data 的替代方案具有更好的人因設計，最重要的原因是這些替代方案不依賴以套件名稱為基礎的脆弱合約，也不依賴「遠端動作」。

回溯相容性

有時需要以軟性轉換方式，從 config-data 遷移至其他服務。在轉換期間，使用設定資料的元件必須能夠接受兩種輸入格式：config-data 和所選的替代方案。

安全性考量

這項 RFC 並未引入任何新的設定機制，我們用來取代 config-data 的所有機制都已存在於系統中，且已通過安全性審查。元件作者在設計或變更安全性相關功能的設定時，應諮詢安全性團隊。

隱私權注意事項

這份 RFC 並未引入任何新的設定機制，我們用來取代設定資料的所有機制都已存在於系統中，且已通過隱私權審查。元件作者在設計或變更隱私權敏感功能的設定時，應諮詢隱私權團隊。

測試

config-data 提供的替代方案都已建立測試最佳做法。如需特定功能的測試資訊，請參閱說明文件。舉例來說，請參閱使用 Realm Builder 測試結構化設定的指南。只要按照下列步驟操作，就能輕鬆取代測試中的結構化設定值：

realm_builder.SetConfigValue(child_name, key, value_for_test);

當我們需要將設定資料以檔案形式提供給測試中的元件 (例如在整合測試中) 時，可以將檔案與測試一併封裝，然後從測試元件 (位於測試領域根目錄) 將檔案以資料目錄形式路由至測試中的元件。例如：

{
    ....
    capabilities: [
        {
            directory: "test_config",
            rights: [ "r*" ],
            path: "/test_config",
        },
    ],
    children: [
        {
            name: "component_under_test",
            ...
        },
    ],
    offer: [
        {
            directory: "test_config",
            from: "self",
            as: "config",
        },
    ],
}

說明文件

為支援從 config-data 遷移，我們會提供遷移指南。遷移指南可協助開發人員選擇最適合其用途的替代方案，並提供其他說明文件。

關於人力和流失率的附註

接受此 RFC 不會對 config-data 現有使用者施加任何要求，要求他們遷移至新式替代方案。如果您已指派遷移工作，則應有核心遷移團隊負責執行大部分工作。作者建議，在 CFv2 遷移完成前，不要開始這類工作，但我們應該加快腳步，並完成回歸停止點。

在有專人負責遷移作業之前，允許清單的更新作業 (例如支援重構) 應在 1 個工作天內審查並核准。

缺點、替代方案和未知事項

結構化設定是一種新機制，仍在不斷改進中。舉例來說，有些用於表達設定所需的功能 (例如其他資料類型) 尚未實作。

能力路由目前不受平台版本控制的影響。我們計劃支援在 ABI 修訂版本中調節能力路徑，但這項機制尚未設計完成。