RFC-0182：淘汰 config-data

摘要

這項 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 和目前的替代方案。
• 建構團隊：負責維護 config-data 建構時間邏輯。
• 軟體組裝團隊：負責維護組裝時間邏輯。config-data
• config-data 的現有使用者，涵蓋許多團隊。

協助人員：

• hjfreyer@google.com

審查者：

• aaronwood@google.com
• adamperry@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

社交：

這項 RFC 的草案在發布前，已由元件架構和軟體組裝技術主管審查。

背景

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 資料和時區資料：ICU 程式庫的資料，尤其是時區資料 (「tzdata」)，會在執行階段以 config-data 形式提供。在 Fuchsia 平台來源中，為這些資料檔案定義單一資料來源，並將檔案提供給各種來源的元件 (例如 Chromium、Flutter、Google 內部存放區等)，確保只使用這些檔案的一個修訂版本。這樣可確保一致性 (例如，所有元件都會同意使用單一 tzdata，無論來源為何)，並提高效率 (所有元件都會共用相同的 ICU Blob，無論建構時間或地點為何)。
• buildinfo 和 hwinfo 元件的值會以 config-data 形式提供。這些元件是根據平台原始碼建構而成，但可能需要由產品設定。目前 config-data 是這項設定機制。
• 設定 UI 元件 (定義於平台來源) 可設定為在不同裝置上以不同方式運作，這些裝置會公開不同的硬體切換開關。舉例來說，在 Astro 裝置上，SetUI 的行為與 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 的所有機制都已存在於系統中，且已通過各自的隱私權審查。設計或變更隱私權敏感功能設定時，元件作者應諮詢隱私權專家。

測試

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 修訂版本中建構對調變能力路徑的支援，但這個機制尚未設計完成。