RFC-0127：結構化設定

RFC-0127：結構化設定
狀態已接受
領域
  • 元件架構
說明

可解決一組常見元件設定問題的全新設定系統。
問題
毛皮變化
作者
審查人員
提交日期 (年-月-日)2021-07-08
審查日期 (年-月-日)2021-09-22

編輯此 RFC

編輯 RFC 中繼資料

摘要

此 RFC 提出新的「結構化」設定系統 開發人員可以輕鬆並一致地解決一組常見的元件設定 來解決生成式 AI 相關問題這項功能的用途是補充資料，而非 取代 Fuchsia 現有的設定機制。

元件開發人員可在 接著，元件架構會將設定值傳送給 每次執行個體啟動時，系統都會更新元件已定義初始設定值 進行整合如果組合時間允許，設定值也可以 在系統由元件的父項或 FIDL 執行時設定 存取 API

此 RFC 涵蓋了動機、預期用途以及整體設計。未來 RFC 會定義實作方式，以及開發人員用來與 運用這個新系統

提振精神

如果軟體可以經過「設定」，軟體更靈活且可重複使用；也就是如果 可以由外部控制，而不是由 並產生原始碼Fuchsia 適用於 大規模的實際工作環境您必須啟用設定 以便確保平台持續進化。

其他大型平台提供基礎架構，可協助開發人員 (例如 Chromium) Fuchsia 的設定目前為手動過程，需要自訂工作 同時在執行階段使用設定值 設定值

Fuchsia 設定中最常見的設定工具目前正在讀取檔案 從 config-data 套件讀取資料，並從 設定導向 FIDL API這些現有工具已用於解決 目前有幾個重大問題，但並未廣泛使用 。

此 RFC 提出新的「結構化」設定系統 開發人員可以輕鬆並一致地解決一組常見的元件設定 來解決生成式 AI 相關問題這項功能的用途是補充資料，而非 取代現有的設定機制

啟用簡單一致的元件設定有許多好處 ，例如：

  • 平台元件也能提高靈活性，以支援更多 很少直接解答該如何打造產品
  • 只需提供 可取代 CFv1 在啟動子項時提供引數的功能 元件。
  • 您可更安全地將新的平台和產品功能部署至實際工作環境 跨越功能越好
  • 開發、測試及維護可設定成本的相關成本 進而減少整體行為

相關人員

此 RFC 的利害關係人是 Fuchsia 工程委員會，「元件」 範圍增加的平台團隊 (即元件架構和軟體 推送) 和團隊，共同努力改善 (PDK 與安全性)。

系統的潛在用戶端也很重要，但因為此 RFC 不行 一個通用的設定系統，此系統不應滿足所有 所有潛在客戶的偏好。

講師：Abarth

審查人員：geb (元件架構)、 wittrock (SWD)、aronwood (SWD &PDK)、Apearce (安全性)

顧問：ddorwin、hjfreyer、ejia、thatguy、shayba、jamesr、ypomortsev、 crjohns、surajmalhotra、curtisgalloways、adamperry

社交：此設計或先前文件的初期草稿是 在「元件架構」、「安全性」、「軟體推送」、「Cobalt」和 和 PDK 團隊合作還在與潛在客戶進行數次討論。

用途

常見用途：功能旗標

為已部署的系統新增功能可能會帶來風險。全新設計 而且新程式碼偶爾會包含錯誤或無效假設 直到部署到實際工作環境。其他 為降低此風險，平台可以使用「功能旗標」：布林值 設定參數，用來控制功能是否啟用。 功能旗標的優點如下：

  • 新軟體版本的部署與啟用新的啟用分離 功能；透過該軟體版本新增的功能，不一定要 同時啟用和啟用狀態
  • 如要正確操作新功能 可以在啟用此功能前徹底測試。
  • 每項功能都可以在各裝置上逐步啟用，其中一種方法是使用發布版本 版本、百分比階段或兩者的組合
  • 必要時，您可以安全快速地停用每項功能；停用 功能也不會需要復原至先前的軟體版本。

我們以最近推出的功能為例， 功能旗標：導入頻率預估功能， 計時工具。在提交的 CL 中，這項功能是立即運作 永久啟用。

estimator/mod.rs (不含結構化設定)

match self.frequency_estimator.update(&sample) {
  // use resulting frequency update
  ...
}

透過結構化設定，我們才能宣告功能旗標 元件資訊清單使用頻率 加入此標記的 estimator：

timekeeper.cml

{
  ...
  config: {
    enable_frequency: {
      type: "boolean",
      default: "false"
    }
  },
  ...
}

main.rs

import config_timekeeper as config;
...
let config: config::Struct = config::parse();
// Pass config through to each new Estimator

estimator/mod.rs

if self.config.enable_frequency {
  match self.frequency_estimator.update(&sample) {
    // Use resulting frequency update
    ...
  }
}

在此範例中，在資訊清單中宣告設定區段會導致建構 系統產生程式庫，內含該程式的 FIDL 結構定義 以及填入此結構體所需的程式碼 執行元件提供給元件的輸入內容實作 元件就能匯入此程式庫，並使用結構中的欄位來控制 運作原理

請注意，元件開發人員可以使用約 10 行標記在標記後方開放新功能 程式碼他們可以獲得什麼來換取這 10 行的程式碼？

  • 這項功能一開始會在所有地區停用。由於元件 如果作者提供預設值「false」，這個標記就會停用，直到 則明確設定不同的值。

  • 系統執行時，一開始就無法啟用這項功能 正式版。哪些設定鍵可以在 系統正在執行政策問題，且這個 RFC 未指定政策。 不過，為了安全起見 允許用於正式環境 (例如「user」) 發布作業，除非有明確要求 並經過審查

  • 開發人員可以在系統工程期間測試此功能 發布版本。在系統維護期間，哪些設定鍵可以變更 運作有政策問題，且這個 RFC 未指定政策。不過， 可簡化開發、測試及偵錯工作 對工程中的大多數設定鍵 (例如"eng") 發布。 開發人員可以使用 ffx 在本機裝置啟用這項功能。 例如 (使用名詞語法)：ffx target config set timekeeper.cml enable_frequency=true。如果政策允許，開發人員也可以啟用 這項功能，以便在裝置重新開機後持續運作。

  • 測試可以涵蓋「功能已啟用」和「功能已停用」案例 如果是單元和元件層級的測試，就需要手動建構 插入 FIDL 設定結構；進行整合測試時，此結構會包含提供 為受測試的元件啟動 (例如使用 Realm Builder。

  • 建構與組合工具可在平台中運作 界線。建構及組合工具目前正透過 DPI 和 SPAC 工作。這項工作的結果 讓平台維護人員能控管 暴露在產品中的風險根據政策和功能風險 平台可以控制功能的推出作業 如果是較複雜的情況，平台 系統持續執行時，即使在 (例如「user」) 發布。這樣一來，產品就能啟用 功能，例如設定 根據實驗推出系統或企業管理控制台執行。

  • 標記狀態會反映在裝置指標中。適用於下列標記的版本 狀態都可以變動 額外雜湊，可用來區分已啟用功能的同類群組 也就是在指標分析期間停用特徵的同類群組

常見用途：產品/遊戲/建構類型量身打造

Fuchsia 是一般用途的作業系統，適用於各種用途 不同的產品和裝置類別這意味著平台有時會 元件必須根據 產品或遊戲板

我們來看看 Timekeeper 的另一個例子： 世界標準時間維護演算法必須確定 裝置的調節工具，以便瞭解錯誤界限和權重的成長幅度 連續樣本。有些調節器的準確度明顯較高 ( 成本高昂！) 想進一步表達想法嗎？ 系統採用板型變化版本，因此目前已以硬式編碼方式寫入解碼器錯誤：

estimator/mod.rs (不含結構化設定)

const OSCILLATOR_ERROR_STD_DEV_PPM: u64 = 15;

kalman_filter.rs (不含結構化設定)

static ref OSCILLATOR_ERROR_VARIANCE: f64 =
    (OSCILLATOR_ERROR_STD_DEV_PPM as f64 / MILLION as f64).powi(2);
...
self.covariance_00 += monotonic_step.powf(2.0) * *OSCILLATOR_ERROR_VARIANCE;

透過結構化設定，我們能宣告整數 然後設定「時間記錄」資訊清單中的 產品或開發板提供的 ID：

timekeeper.cml

{
  ...
  config: {
    oscillator_error_std_dev_ppm: {
      type: "uint8"
    }
  },
  ...
}

main.rs

import config_timekeeper as config;
...
let config: config::Table = config::parse();
// Pass config through to each new KalmanFilter

estimator/mod.rs

// Delete hard-coded constant.

kalman_filter.rs

let oscillator_error_variance: f64 =
    (config.oscillator_error_std_dev_ppm as f64 / MILLION as f64).powi(2);
...
self.covariance_00 += monotonic_step.powf(2.0) * oscillator_error_variance;

與第一個應用實例相同，元件開發人員可以介紹這個可自訂的 參數，內含約 10 行的程式碼，並接收相同的實用屬性。在本 資訊清單並未提供預設值 (因為元件 作者不知道調節器的理想或壞處)，因此 如果沒有任何其他輸入內容提供 值。

其他使用情況

先前的章節介紹了 Google Cloud 的兩項常見用途 也能透過同一系統解決 當中包含許多其他簡易設定用途例如：

  • 禁止測試旗標：有些元件會自然呈現 造成整合測試困難 (例如時間系統具有 5 個 的等待期)。僅供測試用的旗標 在整合或端對端測試期間禁止這些行為。

  • 元件執行個體建立時間設定。有時候 您必須先 要建立的每個元件執行個體您可以將設定鍵 讓父項建立新的元件執行個體提供設定值 就在建立時這種做法可以取代 launch args 的用法 ，並支援針對不同的元件自訂元件的多個執行個體 角色 (例如，每個有效帳戶都會啟動一個 AccountHandler 執行個體)。

  • 進行簡單的 A/B 版本測試。想打造最佳設計有時需要 同時嘗試兩種以上的選項，分別在一組不同的 裝置。可存取伺服器端實驗系統的產品可能成效 使用此實驗系統進行設定值 A/B 版本測試 一或多個元件

哲學

結構化設定的設計由以下四個全等理念驅動：

  • 簡單這套系統必須簡單易用，且設計考量 變得容易理解及分析簡單易用，可促進採用並 支援「可靠性」和「安全」哲學家
  • 可靠。可靠性可簡化開發和偵錯作業， 安裝給 Fuchsia 運作的關鍵元件 裝置。
  • 安全。安全性與 Fuchsia 的平台目標直接一致， 如此，系統就能用於攸關安全的元件 Fuchsia 裝置。
  • 可測試。設定會將新的輸入內容新增至元件，因此 也可能出現新的問題開發人員必須能夠完整測試 對這些新輸入元件的回應

範圍

結構化設定不是 設定問題不同建構產品的設定需求 Fuchsia 的規模龐大，當中的需求也經常相互牴觸 要滿足所有需求，會非常複雜 (反之，如果失敗的話， 簡單哲學和威脅另外三個哲學 且過於籠統 (有鑑於無法針對存在 確保穩定性、意味和可稽核性所需的資料 安全理念)。

相反地，結構化設定是為瞭解決一系列常見用途而設計 這一切都很實用元件可以使用一般檔案或 API 式解決方案 解決其他設定問題。尤其是結構化設定 不打算解決下列問題：

  • 數量龐大且複雜的設定資料。大型且複雜的資料 難以稽核，並透過一般工具選擇性限制 可能會與安全理念產生衝突這類資料通常需要額外的 特定領域專屬的解釋和驗證 設定系統前無人知曉最後，大型和複雜的資料 整合多個來源的難度，限制 系統運作時，組裝工具以及覆寫設定的能力 備用資源

    • 需要大型且複雜設定資料的元件應讀取此 檔案中的資料

  • 經常變更的設定資料。經常變更的資料 是多次交付到單一元件，而不是只提交一次 啟動元件這會導入新的故障模式，並 元件複雜性互相衝突 哲學家而且測試也困難許多。請注意 經常不符合我們對「configuration」的定義。

    • 需要設定資料且經常變更的元件 並透過 FIDL 通訊協定接收資料。

  • 其他元件所設定的設定資料 (父項元件除外) 和管理員元件)結構化設定支援父項元件 為元件建立和支援的元件進行設定 管理元件會設定裝置的所有可變動設定。 結構化設定並未提供 任意元件來設定特定物件的設定子集 元件。

    • 其他任意元件需要設定資料集的元件 系統應透過 FIDL 通訊協定接收這類資料 可透過服務轉送功能存取

  • 使用者控管的設定資料。組態 由使用者 (而非開發人員或管理員) 控管， 存取 API此使用者介面無法執行「由其他人員設定的設定資料集」 「元件」可能會失敗 經常」測試。

    • 請納入由使用者控管的設定，並納入 fuchsia.settings，或採用類似方法 ，將前端與後端元件分開。

「設定」的定義

元件會取用多種不同的輸入。這些輸入內容 可能改變元件的行為，但只有部分輸入內容 視為「元件設定」而不是一般的「系統狀態」 或「輸入資料」

就此 RFC 而言，我們視為「configuration」做為輸入內容 每個元件執行個體都會使用該元件，根據其作業情境調整作業 更新產品 (例如產品、開發板、建構類型、管道、法規區域或 整合測試領域)。設定值在生命週期內會維持不變 ，而且在某些裝置上通常都是固定的。 設定值通常是由開發人員、維護人員或 而非一般使用者

資料類型

結構化設定適用於中等界限且可妥善運用 為每個元件定義設定鍵限制 因此能製定妥善的說明文件 可測試、最小可變動性，且易於稽核。這麼做也能啟用 自動組合來自多個來源的設定這些詞彙的定義明確 組合鍵/值組合會建立「結構」「結構化設定」中

我們不打算支援位元組或任意長度的字串，因為 「任意大型且複雜的設定資料」限制。其中一組 後續支援的資料類型會定義，不過會包含 小於或等於布林值、整數、有限制長度的字串，以及這些 資料類型 (清單長度有限，且清單中所有項目都是 )。

對列舉的支援日後非常理想，但較為複雜 因為在組裝和 執行時間) 必須能夠存取一組有效的列舉器。開發人員工具 如果系統能轉換列舉名稱之間的互譯，會更符合人體工學 但這樣會增加複雜度

支援可組合清單 (即支援下列項目的清單： 多個設定來源 變得相當複雜具有操縱設定鍵的不可分割類型 意味著只是替換其值，但是可組合項需要更複雜的 像是附加、插入或移除值或合併清單 片段。這些作業需要在組裝和 而且會建立新的失敗模式，例如無法插入項目 因為這麼做會超過清單長度上限。系統必須 區分哪些清單項目順序不會影響 因此，應該在此處使用 部分標準順序)，並列出項目順序影響 (以及 因此，必須明確設定操縱，才能 順序)。

元件架構版本

結構化設定僅支援元件架構 v2 元件。是 這個大型專案涵蓋許多領域，因此還沒準備好廣泛採用 直到 2022 年初為止支援兩種不同的架構 擴大放送範圍，並將結束日期延後到 第 1 版元件

設計

總覽

本節將概略介紹系統的整體設計。 下列各小節將詳細說明這裡介紹的各個步驟。

設計摘要如下圖所示：

此圖顯示系統中頂層的互動，如下文所述。

可設定資料的每個元素都是鍵/值組合。元件作者宣告 其元件設定鍵 (以及選擇性的預設值) 以及建構系統與元件架構 負責將設定值提供給 。

建構和組合程序會產生設定檔定義檔 ，其中包含設定鍵資料類型和名稱，以及設定 值檔案，其中包含每個設定鍵的值和可變動性。於 這兩個檔案的初始實作項目，都放在 套件為元件 )。詳情請見下方的替代文案 3。 提出合理理由並就未來方向進行討論。

每次啟動元件執行個體時，元件架構都會檢查 其中包含設定定義檔案如果設定定義 ，該元件架構結合了 含有父項元件提供之任何值的設定值 與設定覆寫服務提供的任何值 遵循設定檔的可變動性限制。 元件架構會將這些合併的值傳送至新的元件執行個體 即可開始使用任何最適合執行階段的技術

元件架構提供新的 FIDL 介面，可供開發人員工具或 產品元件可以使用產品元件查詢設定值 覆寫值下次擷取新值時，系統就會採用這個介面設定的新值。 元件執行個體啟動。

檢查和因此會納入設定值的統計資料 包含在快照中來協助偵錯設定值的雜湊 如果是組裝時間的差異，則會透過 Cobalt 回報各項元件 即使裝置採用不同的設定值，也能評估 以便獨立作業

設定定義

元件作者可以定義設定鍵 (每個索引鍵都具有資料類型 (選用) 元件資訊清單預設值)。後續工作會定義 但確切的語法可能如下所示：

{
  program: {
    ...
  },
  config: {
    enable_frequency: {
      type: "boolean",
      default: "false"
    },
    oscillator_error_std_dev_ppm: {
      type: "uint8"
    }
  },
  ...
}

在初始實作中，所有鍵都是在單一「平面式」中定義。命名空間 但將設定鍵中的法律字元限制為 [-_a-z0-9]。如果系統將巢狀或分組的設定鍵視為重要 日後您可以使用以點分隔或 以斜線分隔的語法

某些執行階段 (例如投放和網頁) 會產生 CFv2 ComponentDecls 而非元件資訊清單一開始使用這些執行階段 不支援結構化設定

在資訊清單中加入設定部分，會導致元件建構規則 產生一個程式庫，內含該設定適用的 FIDL 資料表定義，並 系統需要透過提供給 執行元件接著，元件的實作內容會匯入 這個程式庫，並使用表格中的欄位控制其行為。

元件資訊清單同時說明瞭元件的需求與合約 元件必須可處理在此 RFC 之前，*_binary 建構規則並未 取決於 fuchsia_component 建構期間的資訊清單內容 對二進位檔具有選用性的依附元件建構規則的一些變更 以避免循環依附元件

在某些情況下，單一二進位檔會由多個元件使用。這些案件 需要進行一些重構，才能使用結構化設定。選項之一 確保所有元件都是透過包含 常見的 CML 資料分割另一種做法是將元件合併成 單一定義，並使用結構化設定來說明 先前透過不同資訊清單表示的行為

建構、組合及發布

建構、組合和發布程序負責產生兩個檔案 為每個可設定元件建立欄位這兩個檔案會放在與 元件 (日後也會擴大支援提供值) 請參閱這個替代套件。

設定定義檔案

這個檔案含有每個設定金鑰的下列資訊：

  • FIDL 欄位編號
  • 欄位名稱
  • 資料類型

這項資訊已在元件資訊清單中提供，因此這個檔案 在元件建構過程中產生的 YAML 檔案建議一併計算 並在設定定義檔案中的所有資訊中加入雜湊值 做為設定版本 ID

請注意，我們會以「檔案」來簡化 但可能會在實作中 資訊 (即*.cm 檔案) ，而非單獨的檔案

設定值檔案

這個檔案含有每個設定金鑰的下列資訊：

  • FIDL 欄位編號
  • 設定值
  • 由 ChildDecl (布林值) 可變動
  • 由覆寫 (布林值) 可變動

檔案格式未由此 RFC 定義。

在成熟且可擴充的組件系統中，有幾個不同的發動者可能想 為一或多組金鑰指定或限制這項資訊。例如： 元件編寫者、董事會工程師、平台邊界擁有者、產品 整合商或安全性審查人員實行這項機制需要幾項工具 目前正透過 DPI 和 SPAC 政策執行相關作業 平台藍圖項目，且這個 RFC 並未指定這些工具將如何 來產生設定檔

在這段期間，結構化設定只由少數 我們會將這類檔案手動維護 原始碼存放區如果以樹狀結構建立的產品需要修改 預設應用程式元件設定，取代 安裝於平台套件中

組合程序必須驗證設定值的內容 檔案與對應的設定檔 (即 這些物件包含一組相同的欄位編號，而且資料類型 保持一致

VBMeta

建議您在使用 Cloud VPN 時，從產生的正式版本 同一張圖片舉例來說，假設您使用 開發金鑰，並在簽署正式版時停用。使用相同的 ，可降低實際工作環境和實際工作環境之間，發生意外差異的可能性 並可能減少我們維護的映像檔數量。

我們日後著手支援這項功能，方法是允許部分設定值： 會在 vbmeta 中覆寫VBMeta 是 Fuchsia 機構採用的中央資料結構 驗證開機程序，且內含 推出 Fuchsia 版本。因為 vbmeta 已簽署，因此設定值 被 vbmeta 覆寫的就會包含在已驗證執行的情況下。

若利用 vbmeta 設定，可以建立多個版本時能創造更多價值 這些發布內容可能有實質差異 提供實用行為而這需要用到多個基礎架構元件 已與結構化設定整合 由 vbmeta 設定。

元件起始

每次啟動元件執行個體時，元件管理員都會解析 設定檔和設定檔 內容來判斷哪些來源可以提供設定值。 下文將詳細說明這些來源。元件管理員 結合來自來源的貢獻，產生最終 設定值

決定設定值後，元件管理員會 將這些值傳送給執行元件執行器會將設定值傳遞給 產生了最獨特的新啟動元件在許多情況下 我們希望這項呼叫會傳遞新的 procarg，其中包含控制代碼 並啟動含有該 FIDL 資料表的 VMO。在某些情況下，您可能需要 將設定視為 key=value 指令列引數

元件可以相信架構一律會傳遞設定 值，且 失敗並顯示嚴重錯誤。元件一律不得定義 內部預設值以配合缺少的設定，這麼做 導致執行階段錯誤改變了原本有意在 。

包含該版本的值

最簡單的情況是設定值檔案內提供的值。 使用方式。如果設定值檔案指出元件沒有任何 設定鍵可由 ChildDecl 調整，但可藉由覆寫 一律在這個情況下，元件管理員不必查詢 設定覆寫服務

這個流程如下圖所示：

此圖呈現元件期間的互動關係，如上文所述。

使用 ChildDecl 的值

我們會展開 ChildDecl，納入以下向量的向量： 可有效取代 CFv1 提供 啟動新元件執行個體時的指令列引數。ChildDecl 可能會 由父項提供，將新例項新增至元件集合，由 測試環境的建構過程 父項元件資訊清單。

如果 ChildDecl 中有設定，元件管理員就會：

  • 驗證設定檔中的 ChildDecl 金鑰 並使用正確的資料類型
  • 透過設定中的 ChildDecl 可修改 ChildDecl 金鑰 值檔案中，
  • 使用 ChildDecl 值填入提供的鍵。
  • 使用設定值檔案填入其餘的鍵。

元件管理員會記錄資訊性錯誤，如果有，系統會傳回錯誤 鍵不存在、包含錯誤的資料類型，或是無法變動 ChildDecl，

此流程由呼叫 CreateChild 的父項元件啟動，示意圖 如下：

此圖呈現元件期間的互動關係，如上文所述，使用父項元件的設定。

使用覆寫服務的值

如果設定檔狀態檔案指出一或多個設定鍵 「可覆寫」 元件管理員會向設定發出 FIDL 要求 可以覆寫服務以取得覆寫值這項要求包含元件 新元件執行個體的執行個體 ID 和帳號代碼 加入設定檔定義檔中回應會包含 空白) 一組要套用的覆寫設定值。

設定覆寫服務的常見實作方式為 「設定覆寫管理員」但設定覆寫值 服務會透過元件拓撲轉送為能力 (類似 儲存功能，並使用字串進行參數化) 拓撲的不同部分可能會使用 覆寫服務 API 的不同實作方式

設定覆寫管理員會保留「已覆寫」的資料庫 設定鍵/值組合，透過 FIDL 編輯，如下所述。每個項目 是在元件執行個體層級定義，並由 元件執行個體 ID (請參閱這個替代方案， 其他理由)。每個覆寫項目都會儲存在磁碟上 在整個重新開機後仍持續存在，或在 剩餘時間 目前的供電週期。在建立項目時指定持續性。

收到設定覆寫要求時，系統會覆寫設定 經理：

  • 檢查覆寫資料庫中的項目。
  • 驗證設定檔案中出現覆寫的鍵 並使用正確的資料類型
  • 傳回相符的鍵/值組合。

設定覆寫管理員會記錄說明錯誤，並刪除 資料庫項目 (例如，找不到鍵或資料類型不正確) 如果在設定 設定覆寫)。

在接收設定覆寫回應時，元件管理員：

  • 在設定中透過覆寫的方式，驗證遭到覆寫的鍵是否能變動 值檔案中，
  • 使用覆寫的值填入覆寫的鍵。
  • 使用設定值檔案填入其餘的鍵。

如果元件管理員未收到來自設定的有效回應 覆寫服務，導致元件啟動失敗

在這個流程中，如果設定覆寫管理員將 設定覆寫服務的說明如下：

此圖呈現元件期間的互動，如上文所述，開始使用覆寫的設定。

請注意，設定鍵會以字串的形式儲存在覆寫資料庫中。 隨著元件演進，設定欄位組可能會有變動 但設定覆寫依然有效，只要鍵名和資料類型 也不會變更以最佳化上次出現的設定版本 ID 和 也可在資料庫中快取欄位編號。

值選取摘要

將這些資料流放在一起後，元件管理員會為每個流程選取值 設定金鑰如下：

  1. 如果鍵可透過覆寫功能變動，且系統從 設定覆寫服務，請使用這個值。
  2. 否則，如果鍵可由 ChildDecl 提供，且 ChildDecl，請使用這個值。
  3. 否則，請使用設定檔的值。

設定 FIDL 介面並覆寫資料庫

設定覆寫管理員公開了兩項 FIDL 服務，可用於 如何與覆寫資料庫互動

  1. 這項服務可以：
    • 讀取所有設定覆寫值。
    • 建立及刪除儲存在記憶體中但未保留的設定覆寫設定 會在設定覆寫管理員重新啟動後持續保留
  2. 這項服務可以：
    • 讀取所有設定覆寫值
    • 刪除所有設定覆寫值
    • 建立儲存在記憶體中但不保留的設定覆寫項目 跨設定覆寫管理員重新啟動
    • 建立覆寫設定，覆寫磁碟中儲存的設定，並保留於 設定覆寫管理員重新啟動次數

第一項服務無法針對設定和 適用於自動化端對端測試這兩項服務都屬於機密性質 已加入許可清單。

我們會介紹一種使用第二項服務的 ffx 外掛程式，讓開發人員 查詢及修改測試裝置上的設定。這組設定 若是特定版本中可透過 FIDL 編輯的鍵，就屬於政策問題 而不是由這個 RFC 定義，但我們認為在 eng 版本中 限制透過 FIDL 編輯設定。

即使覆寫資料庫中的項目已根據設定驗證 定義檔案之後，項目可能會隨著 移除元件或升級至包含不同 設定金鑰我們透過下列幾種垃圾收集措施解決這個問題：

  • 覆寫資料庫中的每個項目都有到期時間，期限過後 將遭到刪除。在實際運作系統中，我們會考慮設定到期時間 強制規定。
  • FIDL 服務包含簡便刪除多餘項目的方法 包括刪除元件執行個體的所有項目，以及刪除 整個資料庫
  • 在未來，我們將調查從軟體接收通知 移除或升級套件時放送，因此會做出相應覆寫 項目可能遭到刪除或重新驗證

診斷

請務必瞭解元件所使用的設定，以利偵錯 如要解決關聯問題，可用 Apriori 這類關聯規則學習技術和演算法區分指標與執行不同裝置的裝置同類群組 設定對於評估部分推出和 A/B 研究而言至關重要

大多數裝置上的設定鍵都會使用組合期間設定的值。 開發人員必須知道應用程式的發布版本 (如果應用程式 可向上) 推斷設定值。每當元件執行個體 元件管理員會計算兩個雜湊：「ChildDecl 設定」， 雜湊」套用至 ChildDecl 的所有設定鍵和值 「覆寫設定雜湊」當中的所有設定鍵和值 已由覆寫設定傳回如果沒有設定任何欄位，則對應的雜湊值將 零時差弱點

如果使用這些設定時有中等數量的不同設定 雜湊值足以識別各個同類群組。如果是大量工作負載 設定值 (例如開發人員 測試期間網址) 使用設定雜湊可能不足以判斷 這些配置值仍會指出使用 以及使用 Google Kubernetes Engine 為同業套用不同的設定

記錄

元件管理員會記錄每個元件計算的統計資料 但不會記錄原始設定值設定覆寫 管理員會記錄所有 FIDL 要求，並修改覆寫資料庫。

檢查 &快照

元件管理員的檢查資料包含 來協助偵錯包括 每個來源所設定的設定值和設定雜湊值 。由於快照包含檢查資料，因此 所有執行中元件執行個體的設定雜湊都會包含在 完全不必建立快照

其中設定鍵對於伺服器作業和偵錯作業的重要性 元件時，元件可以選擇 各自的檢查資料

鈷豔藍

元件管理員會將兩個設定雜湊傳送至 開始 (透過執行元件)。我們擴大 fuchsia.metrics.MetricEventLoggerFactory 到 建立新的 MetricEventLogger 時，系統會接受這些雜湊。

Cobalt 將這些設定雜湊與現有 SystemProfile 欄位，用於定義元件執行的位置。 允許分析不同設定裝置的指標 。標準閾值仍然適用，因此 當某些最低裝置數量相同的設定時即可使用。

實作

我們會選擇少數「搶先體驗」元件使用 但在建構結構化設定期間 不斷進化。

導入作業將分為三個階段 功能：

  • 階段 1：靜態價值
    • 進入這個階段後，您就可以建立設定定義 (可能使用非最終版本的語法和工具) 來放置設定 然後將這些值傳送到位於 的元件執行個體 。
    • 這個階段提供搶先體驗元件行為的基本方式 組合不同產品或建構類型的變數。
  • 階段 2：父項值
    • 這個階段結束後，您就能進一步限制 封裝設定值，以便在 ChildDecl，在啟動時將這些值傳送至元件執行個體。 設定時，必須透過元件資訊清單來定義設定 使用近乎最終的語法
    • 在這個階段，您可以對哪些設定和用途進行整合測試 需要父項元件為子項提供設定。
  • 階段 3：已覆寫的值
    • 階段結束後，您還可以 並透過 FIDL 介面或 ffx 外掛程式覆寫設定 介面、在元件執行個體開始時，將這些值傳送至元件執行個體，以及 在 Cobalt 中依據設定區隔指標
    • 階段會完成此 RFC 中定義的工作，並解除封鎖本機系統 開發人員測試、端對端測試，以及進一步的產品整合。

成效

這個 RFC 會導入一個新元件，產生中型 (普通) CPU、記憶體和儲存空間 。上述所有縮放方式皆採用結構化的元件數量 設定金鑰和設定金鑰的數量

計算設定值會導致系統啟動 因額外的 FIDL 而可覆寫設定的元件 讀取及寫入其他檔案我們會監控這個費用 實作設定覆寫管理工具。

安全性

許多元件可使用結構化設定來控制 使用者行為的不同面向可以修改設定的攻擊者 因此可能會在多種不同類型中 管理基礎架構例如：

  • 啟用偵錯輸出功能，洩漏使用者資訊。
  • 將網路要求重新導向至攻擊者控制的伺服器。
  • 啟用實驗功能並利用 。

此設計包含多項旨在防範這類攻擊的功能：

  • 可設定的資料範圍有限，且每個元素都良好 以便稽核
  • 系統會在簽署版本時為每個設定金鑰定義一個值， 值包含在驗證執行作業中。
  • 在系統執行期間修改設定鍵的功能 版本簽署後，請針對每個鍵和各項異動機制分別執行。 這些變動是由已驗證的執行所涵蓋。
  • 可變動性和預設值是在元件層級定義，而非 元件執行個體層級有不同元件的新例項 只有在 ChildDecl 可變動或可變動的情況下，才可建立設定 系統會針對設定金鑰設置覆寫值
  • 您可以暫時且持續變更設定 顯示為獨立的 FIDL 服務
  • 要變更設定的 FIDL 服務是由許可清單控管。
  • 現有經過充分審查的現有 FIDL 繫結剖析設定資料 而非特定應用程式的邏輯
  • 設定覆寫管理員會是增加目標，因此我們要 安全性審查。

隱私權

結構化設定並非用於儲存使用者設定 ( 不同的穩定性、持續性、存取權和時間需求等) 值一律不得含有使用者產生的資料。這項資訊都會明確記錄 引導使用者操作

這對父項元件將 PII 設定傳送至 動態建立的子項 (例如硬體 UID 或網路位址) 新的元件執行個體應使用)。若不在乎這項資訊 透過 ChildDecl 設定雜湊外洩至記錄檔或指標。這將是 詳細設計期間已擬定所有解決方案，但有數種選項可供使用 (例如 系統可能會在設定定義中標示敏感欄位，然後加鹽 )。

測試

請務必測試多個設定值的能力 確保資料正確性這項設計可讓您測試 所有階段：

  • 單元測試和元件測試可以手動建構 FIDL 設定結構 (即下方元件執行元件提供的結構體) 一般作業) 並傳遞至使用設定的方法。
  • 整合測試可能會為每個元件執行個體提供設定 透過運作範圍建構工具 (使用 ChildDecl) 建構測試領域。
  • 端對端測試可能會在主機裝置上進行其他設定 「透過 FIDL 介面」設定物件您可能需要進行額外作業 暫停一般啟動序列，以免元件發生競爭狀況 。
  • 手動測試可運用 ffx 指令輕鬆設定 設定 FIDL 介面
  • 日後的作業模式會考慮將元件的自動「模糊」功能 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定

如要避免隱含依附元件的 設定覆寫服務例如： 可以使用具有下列特性的設定檔來建構整合測試套件 不允許覆寫和建構測試領域，可避免將 設定覆寫服務

系統將使用以下程式碼來測試結構化設定本身的實作方式 包括單元測試和 元件管理員 - 設定覆寫管理員 -執行元件互動

說明文件

此 RFC 核准後，我們會在 /docs/concepts 發布文件 說明 Fuchsia 及其架構可用的設定機制 關係

一旦語法變穩定並實作結構化設定後 準備開放更多人使用 我們會發布開發人員指南 參考文件

隨著開發人員開始使用結構化設定，並找出 我們也將針對最佳做法和建議風格製作說明文件。

考慮的替代方案

在設定覆寫管理工具中實作設定合併功能

這個 RFC 的先前修訂版本加入了邏輯，合併不同的 元件覆寫管理工具中的設定資料 (隨後已命名的設定) 而非元件管理員)。

這項設計對於元件管理員的範圍較小， 只有元件管理員和設定管理員兩個範圍 定義較不簡潔：

  • 元件管理員必須充分瞭解設定 如何在不瞭解的情況下叫用設定管理員 足以合併值
  • 設定管理員將負責管理部分企業 邏輯，向元件 (以及 資料庫維護作業

這項設計也會增加 FIDL 的情況數量 呼叫。

在元件管理員中實作設定覆寫資料庫

此 RFC 會負責維護設定覆寫 新元件中存放資料庫：設定覆寫管理員替代方案 就是要在元件管理員中執行這項功能

這項替代方法不但會排除 FIDL 呼叫和部分失敗模式， 會是增加元件管理員的複雜性 因此元件經理首次必須保留自己的資料 分配儲存空間供其他元件使用這種儲存空間使用方式 提出額外的安全性問題，且必須在 CF 計畫中使用新的基礎架構。

透過中央套件傳遞設定

這個 RFC 會將元件的設定值加入元件的 套件。另一種方法是，將所有設定 單一設定套件中的元件，類似於 config-data 套件。

傾向於採用分散式方法，而非 集中式做法：

  1. 日後 Fuchsia 將需要執行 基本映像檔 (例如應用程式更新後)。訓練資料中 無法將這些不明元件發布至中央套件 需要其他解決方案
  2. 以完整的方式提交二進位檔及其設定，有助於建立更強的 尤其是在套件可能是 而且會獨立於基礎映像檔更新故障模式較少 導致元件可供使用，但設定無法使用。 或元件的設定不相容

如 RFC 內文所述，我們的去中心化方法目前適用於 設定值，且該套件會與所套用的元件相同。 亦即在組合時間變更時，變更元件設定 其套件的根雜湊。這個情況是不適合的 不支援單一機構 (例如 Fuchsia 平台維護人員) 發布及簽署元件和另一個機構 (例如 產品整合人員) 提供的設定。

未來，我們假設每個套件都包含預設設定值 並列出其中一部分的資料 值可能會透過其他可能發布的不同套件來覆寫 (例如平台元件可以選擇要用 設定「旋鈕」可讓產品整合商存取)。未來的工作內容 定義這個「不同套件」的性質- 選項包括中繼套件 補充資訊套件或包裝函式套件。

依元件網址和路徑名稱覆寫索引設定

這個 RFC 索引設定會由元件的 執行個體 ID。執行個體 ID 可用來為其他項目建立索引 永久性資源 (例如獨立的永久資源) 儲存空間，因此非常適合用於建立索引設定 覆寫值

不過，目前系統會在建構期間手動指派元件執行個體 ID 索引檔這代表執行個體 ID， 設定覆寫功能不適用於 應用程式引進的元件集合或元件執行個體 而非基本映像檔

另一個做法是依元件覆寫索引設定 網址和路徑名稱這會避免執行個體 ID 的限制，但會同時避免 因為系統會重構系統，所以元件網址和路徑名稱 替代方案會造成新的穩定性問題 元件架構永久資源處理時不一致的問題

而是希望透過變更 在未來的 RFC 中設計執行個體 ID

在元件層級支援覆寫設定

這個 RFC 索引設定會由元件的 執行個體 ID，代表元件的每個例項 必須個別覆寫

建議您日後在元件層級支援 除了元件執行個體層級之外這在執行時 在元件多次例項化或元件建立例項時 執行個體不會預先得知

目前還沒有明確定義 可用在元件層級覆寫的元件由於我們 尚未確定有元件層級覆寫的具體需求，我們將延後 包括功能

之前的替代方法所參照的執行個體 ID 設計變更 除了元件執行個體之外，也可以提供穩定的元件 ID 或 ID (例如執行個體 ID 可能是自主認證 ID)， 將某個元件與 需要處理拓撲變更的 Qurks 資料庫)。如此即可簡化 。

使用 FIDL 定義設定金鑰

這項設計使用 JSON 定義元件資訊清單中的設定鍵。 這些資訊的部分會用來建立 FIDL 資料表。另一種替代方法是 請務必先在 .fidl 檔案中定義設定鍵

首先，我們注意到 FIDL 工具鍊是刻意組合的 前端與後端 (以 IR 區隔區隔) 表示您可以使用 FIDL 都不需要以 FIDL 語言定義輸入內容。

決定使用 .cml (而非 .fidl) 主要取決於開發人員 體驗：

  1. 元件資訊清單是開發人員用來描述 所有元件並定義設定鍵， 定義以維護單一檔案來說，與新增檔案相比更有效率。
  2. 可用來定義設定的語法和資料類型為 完整 FIDL 語言的子集 (請參閱範圍)。 如果必須使用 FIDL 語法，但僅支援部分子集，可能也會造成混淆 造成困擾
  3. 設定需要在 FIDL 中無法顯示的資訊 語言 (目前表格欄位的預設值，也可能是其他 限制)。這類資訊可以儲存在「自訂」分頁中 ，但這就與 FIDL 的其他語言版本不一致 且會造成開發人員混淆

其中 JSON 設定定義使用 FIDL 中的概念 我們要使用一致的語法舉例來說，資料類型名稱會是 保持一致

cmc 已透過 JSON 元件資訊清單和 剖析資訊清單中設定所需的額外工作

支援元件之間的設定轉送

元件架構中的許多資源支援從單一元件轉送 複製到其他執行個體 例如通訊協定、目錄和儲存空間 即便沒有技術背景，也能因這些工具的功能而受益如果能在 因此，假設子項可以使用 父項。

這項初始設計不支援設定轉送功能， 也面臨了新的版本管理挑戰如果系統已支援 並用在封裝於不同點的另一個元件中 這是因為這些元件是在不同的存放區中定義 因為我們沒有收到單體式應用程式才送到裝置上 保證編譯至元件中的設定定義與 以及用於設定值的定義我們將於 2023 年推出新的 ABI 但由於這個介面會在 我們無法使用 RFC-0002 管理版本相容性。

如同 PDK 和 PDK，我們可能會進一步討論元件介面和版本 無法進行處理，並延後設定轉送作業 直到模型成熟為止在此期間 可用於在多個套件中提供一致的設定值 無從得知

我們推出了限製版的跨元件相容性 家長可在 Google Cloud 上動態設定子項元件 建立。我們認為這些案件不太可能在短期內造成問題 因為這個可變動性必須 選擇採用且設定欄位 但通常是由子項特別設計，以利使用父項。

針對可重複使用的程式庫支援透明設定。

許多元件是使用可重複使用的程式庫建構而成，且可支援某種形式的 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定在這個 RFC 中定義的結構化設定 只能以手動方式提供此設定透過 kubectl 指令 程式庫需要在其資訊清單中宣告相符的設定鍵 然後在初始化時將設定值轉送至程式庫。A 罩杯 跑者也有類似的情況 因為執行元件可以直接控制 元件執行元件所使用的程式庫中可設定的行為。

替代方案是提供更「公開透明」的資訊設定 程式庫可宣告設定索引鍵，且可能會使用 讓所有設定值直接運作元件只需要宣告 讓設定提供者進行相關設定 值。

如同元件之間的轉送方式 (請參閱上文的替代方法中討論) 也涉及更廣泛、不同軟體的設定金鑰 例如透過樹狀結構元件使用平台程式庫 這樣可能更正式地定義設定，讓設定更加完善 保證設定項目之間的前向和回溯相容性 版本。程式庫的透明設定也會引發問題 瞭解如何將多組設定值傳送給元件。

雖然程式庫的透明設定是 我們會把這項工作延後處理，直到變得簡單、更私密 這個 RFC 中定義的設定系統正常運作，

支援在元件啟動後更新設定

此設計只有在元件執行個體處於 已開始。如果設定在元件啟動後修改， 直到下一個開始為止替代方案 定期套用至元件設定

我們決定以元件為重心，開始與 「設定」繫結至元件生命週期，但也能簡化 元件作者的實作：

  1. 只接收設定一次的元件執行個體可以初始化所有設定 與設定導向的資源一種元件 必須定期接收新設定，才能分配或收集 使資源得以定期更新
  2. 必須定期接收新設定的元件需要一些 也就是定期或非同步處理 無從得知
  3. 必須定期接收新設定的元件也必須記錄 任何設定的任何變更，例如透過診斷連線取得 建立新的 MetricEventLogger 即可。
  4. 必須定期接收新設定的元件則具備 必須處理的錯誤模式，例如 FIDL 終止 連線和逾時。

目前設定在開始後更新設定的需求相當有限： 此版本提供的設定值或透過 ChildDecl 無法變更 並在元件啟動後FIDL 介面可能會在啟動後導入變更，但 一開始只會用於開發人員工具，方便開發人員 在變更元件的設定後自動重新啟動元件

日後，某些產品相關元件可能會想將 更複雜，而不是重新啟動如果不符合，我們就會考慮使用者主動訂閱 讓元件透過 FIDL 接收更新。

既有藝術品和參考資料