平台可更新性後續步驟

Fuchsia 專為更新設計。然而，這項做法也在仍處於開發階段。 本節重點說明一些要提升 Fuchsia 變更和更新能力的進行中或尚未開始的工作。

整個途徑的版本管理和相容性中繼資料

  • FIDL 支援可用性註解。
  • Fuchsia IDK 尚未實作 C/C++ 標頭的可用性註解。實作完畢後，下一步就是將這些註解套用至 SDK 標頭檔案。
  • FIDL API 摘要很適合用來偵測 API 破壞性變更。我們目前有沒有對應的 C/C++ API。系統會將內容雜湊與已知參照進行比對，藉此偵測可能的破壞性變更，而這會產生錯誤偵測。舉例來說，重新設定標頭的格式不會影響 API 或 ABI，但會錯誤觸發變更偵測工具。
  • 支援 vDSO 回溯相容性。舉例來說，如果已知某個元件會指定舊版 ABI 修訂版本，Fuchsia 就能在其位址空間中載入 vDSO 填充碼，藉此匯出舊的 ABI 並呼叫最新的 vDSO ABI。
  • 目前還沒有機制可以指定使用哪個 Fuchsia SDK 版本來建構指定套件或元件。導入這類機制，並透過該機制為預先建構的套件加上註解，對於偵測不相容性而言相當實用。

完成 Fuchsia ABI 遷移至 FIDL 的作業

雖然 Fuchsia ABI 在 FIDL 中大致定義了，但部分舊版 ABI 定義的其他術語則沒有相同可更新用途。

  • 雖然系統呼叫是在 FIDL 中定義，但部分輸入和輸出類型在 Zircon 標頭中仍會定義為 C 結構。舉例來說，zx_object_get_info 是在 FIDL 中定義，但輸出類型 (buffer 參數) 是位元組緩衝區，不像 FIDL 定義，且採用 zx_info_*_t C 結構的格式。
  • processargs 通訊協定用於啟動具有啟動功能的新建程序。啟動訊息的格式會定義為 C 結構，且應轉換為 FIDL。

完成 Fuchsia SDK

以 Fuchsia IDK 和為基礎建構的 SDK 可以用來開發 Fuchsia 元件，而不必查看 Fuchsia 的原始碼，或使用 Fuchsia 自己的建構系統。然而，還有其他開發人員用途尚無法樹狀結構外使用。

淘汰不公開的平台 ABI

您應嚴格定義平台介面的完整性，並以 FIDL 等術語表示，而這些機制可藉由這類機制 (例如版本管理和轉換支援) 提供可更新性。目前平台介面的某些部分不符合這些要求。

  • 部分樹狀結構外元件測試架構會指定平台元件的 fuchsia-pkg:// 啟動網址，藉此啟動平台元件的測試替身。這些網址沒有可更新的預設用途。樹狀結構外元件會自行暴露在平台實作詳細資料中，例如含有特定平台功能特定元件的特定套件名稱。即使 SDK 或平台介面未登錄任何 API 或 ABI 破壞性變更，這些測試通常還是會在 Fuchsia 平台和 SDK 修訂版本之間進行破壞。除了淘汰現有使用措施，我們也會採取措施來避免這些問題再次發生。
  • Fuchsia 的指令碼層 (SL4F) 是用於測試的系統自動化架構。SL4F 的主因是採用 JSON-RPC/HTTPS 通訊協定的主機端測試，並依據現有系統的規格實作。這項決策加速移植龐大的連線測試目錄。不過，JSON-RPC/HTTPS 通訊協定具備與 FIDL 兩者提供的可更新預設用途不同，以及對 ffx 外掛程式的好處，也沒有結構定義。因此，我們後續不應透過樹狀結構外測試來支援 SL4F，並導入替代解決方案。

制定出正式的診斷合約

Fuchsia 支援多項診斷工具，可用於瞭解系統內部狀態及排解問題。內部診斷功能會根據其性質顯示實作詳細資料，顯示程序名稱和階層等資訊。

例如排解系統故障或收集快照時 (例如發生當機情況) 時，這項資訊就非常實用。在這類情況下，您應注意內部實作的詳細資料。不過，診斷結果並不適用於良好的公開合約，

  • 執行階段診斷資訊 (例如特定元件的記錄或檢查屬性) 可在執行階段使用 fuchsia.diagnostics.ArchiveAccessor 功能 (由選取器指定) 讀取。選取器是由元件元件、診斷階層路徑選取器及屬性選取器組成。Monikers 可能會公開平台實作詳細資料，例如拓撲和平台元件名稱。階層和屬性選取器也可以視為實作詳細資料，而且沒有可更新機制。這些是 Fuchsia 產品中樹狀結構外元件的已知執行個體，這些執行個體會使用診斷選取器，在執行階段讀取系統診斷資訊。這些元件會顯示在平台實作詳細資料中，且在詳細資料變更時通常會損毀。對於 Fuchsia 診斷工具之外的用戶端，應移植到使用嚴格定義的 FIDL 通訊協定，以精確讀取所需的資訊。此外，開放式的 ArchiveAccessor 能力應限制，供樹狀結構外結構元件進一步使用。
  • 元件會以不同方式產生診斷資訊，例如「檢查」屬性的內部階層或記錄檔中的非結構化文字。大多數執行此動作的平台元件，不會保證這項資訊的特定結構定義。即使是具有結構和類型的檢查，也不會有執行個體在 FIDL 中找到的所有可更新預設用途。因此，離線處理平台診斷作業 (例如使用 SDK 或產品專屬資訊主頁未提供的工具) 會遇到中斷。
  • 追蹤、CPU 效能監控和 mem 等效能工具會收集並公開程序名稱及其相互關係等的效能資訊。這些資訊有助於調查某些系統的效能，但其反映的是私人實作詳細資料，而非公開合約。

淘汰舊版開發人員工具

我們為 Fuchsia 開發人員提供數種 SDK 工具，其中最重要的是 ffx 和其許多指令。新的 ffx 工具會以 FIDL 中定義的字詞，在主機和 Fuchsia 目標之間互動，藉此確保可更新性。不過，有些舊版工具仍提供給沒有相同可更新用途的樹狀結構外開發人員，

  • 支援 SSH (例如使用 funnel 工具)，並為主機提供類似於目標 Fuchsia 裝置上的遠端根殼層的開發人員體驗。用戶端可能會規避預定的平台途徑，例如直接觀察、啟動及終止系統程序。
  • 我們也同樣支援 SCP (透過 SSH 複製檔案)，並針對全域命名空間和可變動檔案系統提供無限制的存取權，再次規避預定平台途徑。
  • 特定開發人員功能 (範例) 會以舊版殼層元件 (而非 ffx 指令) 的形式向開發人員公開。這會讓開發人員看到難以變更的平台實作詳細資料 (例如套件和元件的名稱)，並將輸入和輸出內容表示為使用者可理解的文字，而不是類型和結構化資料。
  • 部分 ffx 指令 (例如 ffx component) 會公開內部實作詳細資料，例如元件元件和拓撲。這些資料的用途為診斷和疑難排解，而非 API。

相容性測試

您可以使用持續整合與靜態分析工具和建構系統的持續整合，檢查 API 和 ABI 的相容性。此外，Fuchsia Compatibility Test Suite (CTS) 可以測試各種支援的平台和 SDK 版本組合。這些測試可延伸 API 和 ABI 的相容性的概念，以確保保留重要的預期行為。

CTS 專案剛建立不久，涵蓋率相當低。CTS 是一種深度防禦機制，因此擴大涵蓋範圍有助於確保相容性符合預期，即使 CTS 涵蓋範圍完全無法達到平台介面 100%。

其他資訊