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

RFC-0182：淘汰 config-data

RFC-0182：淘汰 config-data
狀態	已接受
區域	元件架構
說明	意圖淘汰舊版機制，以在存放區之間的元件之間提供/使用設定檔
問題	101976 年
變更	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 會使用目標元件的套件名稱不強制執行的合約或慣例來建立「遠處恐怖動作」。這會造成問題，因為套件名稱並不實用，因為套件名稱可以成為 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 blob)。
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 不會引進任何新的設定機制，也就是系統中已存有用於設定設定資料的替代方案，也已通過他們專屬的安全性審查。元件作者在設計或變更安全性相關功能的設定時，應先瞭解安全性。

隱私權注意事項

這個 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 遷移完成後才開始執行這類工作，但我們應該先確認並停止迴歸問題。

在遷移作業有專屬人力配置的時間之前，建議您在一個工作天內審查並核准許可清單內容，例如支援重構。

缺點、替代方案和未知

結構化設定是全新且不斷演進的機制。比方說，尚未實作呈現設定所需的部分功能 (例如其他資料類型)。

功能轉送功能目前不受平台版本管理的影響。我們打算建構在 ABI 修訂版本上調節能力路徑的支援，但這個機制尚未設計。