- 專案負責人：jsankey@google.com
- 區域：元件
問題陳述
如果軟體可「設定」，則軟體較具彈性且可重複使用；也就是說，如果軟體的行為可透過外部控制，而非由其原始碼修正，則會更靈活且可重複使用。
Fuchsia 適用於在多種產品中大規模的實際工作環境，因此可能需要設定的原因有很多。例如：
- 產品工程師根據產品需求，量身打造平台元件的作業方式。
- 軟體工程師在自動化平台測試期間啟用額外診斷或更快速的逾時時間。
- 版本管理員會在正式版管道之前，為產品的 Beta 管道啟用新功能。
- 使用者研究員針對產品生產機群的一小部分進行 UI 變更測試。
- 企業系統管理員會限制企業所擁有及管理裝置的功能。
- 軟體開發人員在開發應用程式時變更系統參數，以探索故障模式。
- 使用者自訂裝置以啟用預先發布版功能。
請注意，這些範例的屬性差異很大。有些屬於「靜態」性質，在建構套件或系統組合時套用設定；其他則為「動態」，會在不變更系統映像檔的情況下套用設定。有些隱含的變更應該在重新開機時持續有效，而其他變更應該只是暫時性的。有些應適用於所有產品，而其他屬性僅可在單一產品情境中使用。
其他平台則提供一或多個彈性的設定機制，能夠滿足各式各樣的需求。舉例來說，Chrome 提供偏好設定、設定、功能 切換鈕與旗標
目前在 Fuchsia 中，平台元件設定主要透過兩項機制執行：
config_data. Build 會建立單一config_data套件，其中包含每個包含可設定元件的目錄。這些元件可以在執行階段從這個套件讀取自己的設定檔。#defines：部分軟體會根據建構系統引數 (例如auto_update_packages) 有條件地編譯。這些引數可在各項產品間改變。
部分平台服務也會公開 FIDL 介面以控制其設定，且可能透過獨立的永久儲存空間或快取，在重新啟動期間保留這些資料。
這些機制已足以處理少數產品中的簡單設定案例，但目前並未開放動態或多層式設定，而已造成許多問題點。例如：
- 設定是在系統映像檔層級進行設定。因此，即使設定有些微差異，也必須新增新產品 (例如
_eng_arrested項產品) - 設定是在系統映像檔層級進行，因此無法 (因為目前缺少樹狀結構組合) 管理外部樹狀結構外
- 修正系統映像檔的設定，因此無法直接對實際工作環境映像檔進行偵錯。例如，「使用者」映像檔不能與不同旗標合併使用，也不能與開發人員金鑰重新簽署，以便在開發金鑰的裝置上啟用 SSH。
- 某些設定會在編譯期間進行，這會限制在各項產品之間重複使用預先編譯的構件。
- 部分區域已針對缺少平台層級設定 (例如模組設定) 而採用特定領域適用的解決方法
- 由於管道中的所有裝置都會同時遷移，因此簡單的遷移作業屬於危險性。安全啟動功能會對元件開發人員造成重大負擔，讓他們能支援平行作業，且暗中啟動 (例如遷移至 HTTPSDate 的概略時間)
- 而
config_data系統是專為 CFv1 建立的系統，而每個套件僅為一個元件的模型。您可以透過「目錄子目錄」功能支援 CFv2，但這種做法相當費時且容易出錯。
解決方案陳述
這項專案仍處於初期階段，需要進一步改善，才能達成需求和解決方案。
透過 config_data 套件傳送至元件的檔案對於平台無法解讀 - 不同的元件使用不同的檔案格式，資料可能相當複雜。Fuchsia 平台無法得知元件預期或接受哪些資料，因此平台無法驗證資料或結合不同來源的元素。接受來自不受信任來源的不透明設定資料，可能會產生一些安全疑慮。
我們認為，必須使用新型「結構化資料」來補充現有的「不透明設定資料」。這些結構化設定資料應具備下列屬性：
- 每個元件都有明確定義所需的資料元素
- 每個資料元素的允許值都明確定義：在許多情況下，布林值、列舉和受限整數均已足夠。
- 這個平台會從支援靜態和動態設定的各種來源彙整結構化設定資料。
- 來源能夠禁止在「較高」圖層進行某些變更，例如，產品設定應能夠防止不相容的功能動態推出。
- 平台會透過執行器等元件，將結構化設定資料傳送至元件 (例如透過執行元件)，而不會與設定資料的來源無關，例如元件無法知道特定資料元素是以動態方式或靜態方式設定。
- 動態設定提供診斷功能，可將錯誤和系統指標變更歸因於導致兩者的實驗和部分推出作業。
下一季我們預期工作會包含以下階段。
第 1 階段
清楚定義可能的設定來源、這些關聯之間的關係，以及用來描述設定變更的關鍵屬性。同意短期和長期支援哪些組合，也是實作時建議採用的機制。這包括說明不同設定形式之間的邊界，例如何時應由系統設定服務處理設定。
這個練習會更明確地定義結構化設定必須填滿的間隔。最終結果應該會與設定設定的 Chrome 參考頁面類似，且應發布至 fuchsia.dev。
第 2 階段
定義並優先執行結構化設定在短期和最終未來必須達成的要求。與 1 至 2 名發布客戶合作，議定 2021 年的行程表和需求。可能的候選項目包括將現有客戶的遷移作業從模組化 (進而遠離模組設定)，或擴展可擴充性產品組合中可能的設定類型。
這個階段的開放問題主要與範圍有關。例如：
- 是否需要支援 v1 元件或非元件化驅動程式？
- 元件管理員應採用與管理元件相同的系統嗎？
- 應針對相同元件設定不同的執行個體嗎？
- 短期內是否需要持續保留動態設定？
第 3 階段
透過 RFC 程序，提出並議定符合這些要求的技術解決方案。
依附元件
在這個階段，結構化設定專案無須依賴其他任何持續執行的專案。
其他專案可能會選擇依附於結構化設定，以啟用部分新能力或遷移作業。舉例來說，將現有產品遷移至工作階段架構，可能會仰賴結構化設定來取代模組設定。
視範圍和時間表而定，結構化設定可能僅適用於元件架構 v2 元件。如果專案要使用結構化設定來將元件 v2 遷移或驅動程式當做元件，專案可能會產生遞移依附元件。
風險與緩解措施
解決方案尚未全面定義，過程中可能會產生其他風險。
目前的主要風險似乎有規律，所以能及時制定結構化設定，滿足第一位客戶的需求嗎？如果同意的技術解決方案，這個風險可能會由更多人員加入專案，有助於降低部分風險。