平台可更新性後續步驟

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 支援多種診斷工具，可瞭解系統的內部狀態，並排解問題。內部診斷工具本質上會公開實作詳細資料，顯示程序名稱和階層等資訊。

這項資訊在排解系統瑕疵問題時非常實用，或是在當機後收集快照時也很有幫助。在這種情況下，內部實作詳細資料就很有參考價值。不過，診斷結果不適合做為公開合約。

  • 您可以使用 selector 指定的 fuchsia.diagnostics.ArchiveAccessor 功能，在執行階段讀取執行階段診斷資訊，例如特定元件的記錄或「檢查」屬性。選取器包含元件代號、診斷階層路徑選取器和屬性選取器。Moniker 可能會公開平台實作詳細資料，例如拓撲和平台元件名稱。階層和屬性選擇器也可能視為實作詳細資料，而且沒有更新機制。這些是 Fuchsia 產品中已知的樹狀結構外元件例項，會使用診斷選取器在執行階段讀取系統診斷資訊。這些元件會公開平台實作詳細資料，且這些詳細資料變更時，元件通常會中斷。平台外部的 Fuchsia 診斷用戶端應改用嚴格定義的 FIDL 通訊協定，準確讀取所需資訊，並限制樹狀結構外的元件進一步使用開放式 ArchiveAccessor 能力。
  • 元件會以不同方式產生診斷資訊，例如 Inspect 屬性的內部階層，或記錄中的非結構化文字。大多數執行這項操作的平台元件，都不會保證這項資訊的特定結構定義。即使是具有結構和型別的檢查，也不具備 FIDL 中所有的可更新性。因此，離線處理平台診斷資訊 (例如使用 SDK 未提供的工具，或在產品專屬資訊主頁中處理)，一定會發生錯誤。
  • 追蹤和 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%。

其他資訊