本頁面由 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 會建立「遠距離的恐怖動作」使用未強制執行合約或符合目標元件套件名稱的慣例這有問題因為套件名稱不像可納入的固定 ID ，並且隨 SDK 推出版本。方法包括宣告支援視窗，並允許柔性轉換。體驗的 AI 技術已證實，以套件名稱為依據的合約會讓執行階段十分簡潔而且維護成本也很高

此外，由於 config-data 會將開發人員套件的內容與擷取來自包含設定檔的基本套件的內容令人困惑的開發人員體驗，開發人員會推動但會在執行階段看到舊的設定檔開發人員經常會問他們為何推送更新版本的套件會在 /config/data 下看到過時檔案，但沒發現這些檔案從其他套件選取物件向開發人員解釋這個行為需要您可以瀏覽平台實作的詳細資料，例如「基本套件」證明抽象化失敗，並非理想的做法甚至還能導致工作效率下滑。

config-data 非常擅長解決問題，協助位於不同的產品組合階段，影響對於無法直接控制使用 config-data 設定值分別源自於存放區、建構系統等模擬來自其他位置的元件行為。

在某些情況下，元件和設定的來源相同，但使用者仍偏好使用 config-data 做為整合點。這能讓使用者產生一個套件，並將不同的設定值側載至這個套件包含的各個元件如果產生的成本有多個套件，比方說，如果每個套件變種版本都需要而是個別上傳至後續的整合點

如今，config-data 已有多種替代方案。包括其他轉送設定目錄的方法目錄功能結構化設定透過通訊協定功能提供服務將設定檔與消耗的元件封裝具體做法是指示 Kubernetes 建立並維護一或多個代表這些 Pod 的物件

雖然無法立即淘汰現有的 config-data 和功能本身，應該將新使用方式引導到現代化解決方案，並提醒現有使用情形的擁有者，改用新型替代方案。

在這種情況下，最佳做法是建立一份使用 config_data() GN 規則，將其初始化為現有使用規則。許可清單預計隨著時間的趨勢趨向於零如果無法確定現代替代方案是否適用，則系統會加入許可清單。時間允許變更，以表明原因，以減少程式碼審查作業的流失問題。

背景

`config-data` 的運作方式

在舊版 appmgr (又稱 CFv1) 中，config-data 是以比對根據 config-data 中的子目錄啟動元件的套件名稱 kubectl 套件如果找到相符項目，會顯示相符的子目錄在已啟動元件的命名空間中，位於路徑 /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 存放區等)，確保僅有一個修訂版本。實現一致性 (例如，所有元件都同意單一 Zdata 無論來源為何) 和效率 (所有元件都共用同一個 ICU) blob)。
buildinfo 和 hwinfo 元件的值應依下列格式提供： config-data。這些元件是以平台原始碼建構而成，但都必須由產品設定目前使用config-data 設定機制
平台來源中定義的設定 UI 元件可設定為在不同硬體平台上的行為不同切換鈕舉例來說，在天文和 Sherlock 上，SetUI 的行為有所不同裝置，且可能受 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 檔案系統中時，檔案大小磁碟中會四捨五入為區塊大小，通常為 8 KiB。封存就會移除四捨五入的額外負擔。這個這點非常重要實際上的總負擔可能會大於這些壓縮資料大小的總和檔案。

使用替代解決方案時，如果儲存空間至關重要，為確保儲存資料的一致性效率。

人體工學

config-data 的替代方法具有更佳的人體工學，最重要的是，並不仰賴以套件名稱為依據的嚴格合約，距離」。

回溯相容性

從「config-data」遷出的作業有時需要十分柔和轉場效果在轉場期間，使用設定資料必須能同時接受 config-data 和以及選擇的替代選項

安全性考量

這個 RFC 並未推出任何新的設定機制，我們可以做為 config-data 做為替代方案，且已經歷過自己的安全性審查元件作者應該在設計或變更安全性相關功能

隱私權注意事項

這個 RFC 並未推出任何新的設定機制，我們可以做為 config-data 做為替代方案，並歷經了自己的隱私權審查元件作者應諮詢配合隱私保護設計，在設計或變更相關設定時接著介紹網際網路通訊層包括兩項主要的安全防護功能

測試

向 config-data 顯示的替代方案均已確立最佳做法。請參閱說明文件，瞭解特定測試功能可能不準確或不適當舉例來說，請參閱結構化測試指南定義運作範圍建構工具。取代結構化設定值測試同樣的輕鬆程度：

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 改用 Pixel，我們會參考遷移指南或更新提示遷移指南可協助開發人員選擇最合適的替代方案並參閱其他說明文件

人員配置和流失注意事項

接受此 RFC 對現有使用者的如要遷移至新型替代方案，請config-data。如果強制遷移的委託書遷移後，則應有人員負責執行大部分工作作者提議，在完成 CFv2 遷移作業後，我們應該立即行動，迴歸停止。

直到遷移人員有專門人員負責遷移之前，如支援重構等許可清單，則應經過審查並獲得核准一個工作天內就能完成

缺點、替代方案和未知

結構化設定是新的且不斷演進的機制。舉例來說表示設定所需的功能，例如額外資料尚未實作。

功能轉送目前不受平台版本管理限制。第一種是建立支援調整 ABI 修訂版本的能力路徑，但這種機制未經設計