RFC-0188：元件 ABI 相容性

RFC-0188：元件 ABI 相容性
狀態已接受
區域
  • 元件架構
說明

偵測元件目標 ABI 修訂版本，並向平台確認其支援。
問題
  • 11051
變更
作者
審查人員
提交日期 (年/月)2022-06-27
審查日期 (年/月)2022-09-31

編輯此 RFC

編輯 RFC 中繼資料

摘要

本文件說明元件架構如何偵測元件的目標 ABI 修訂版本，並在與元件互動前檢查該元件是否與 Fuchsia 平台相容。

提振精神

隨著應用程式和 Fuchsia 系統介面不斷演進，也必須配合平台的成長，監管元件的 ABI 相容性。

元件是利用平台 ABI 的一組行為期望建構而成，不需要強制執行與 ABI 修訂版本明確簽署的 ABI 合約，因此這個期望已成為平台開發的限制。有時候，當元件建構時指定了平台不再支援的 ABI 修訂版本，將會發生。

元件架構可防止執行以不支援的 ABI 修訂版本為目標的元件，同樣地保證平台在執行元件時，可支援元件的目標 ABI。這個 RFC 概述了元件架構在元件與 Fuchsia 平台之間如何強制執行這項 ABI 合約。

相關人員

講師：

  • leannogasawara@google.com

審查者：

  • abarth@google.com
  • etryzelaar@google.com
  • geb@google.com
  • jsankey@google.com

顧問：

  • adamperry@google.com
  • jmatt@google.com
  • lukenicholson@google.com
  • richkadel@google.com
  • wittrock@google.com
  • yeg@google.com

社群媒體化：

這個 RFC 的設計文件與元件架構團隊已完成設計審查。

什麼是元件 ABI 相容性？

ABI 相容性是指 Fuchsia 系統介面對元件提供的行為期望協議。RFC-0002 詳細說明 ABI 修訂版本可能造成的影響，以及平台支援這些修訂版本的方式。

RFC-0002 詳細說明 Fuchsia 平台如何支援不斷演進的 ABI 修訂版本：新增的每個 ABI 修訂版本都會對 Fuchsia 系統介面進行回溯不相容的變更；而舊版 ABI 修訂版本在平台不再支援其行為保證時，會從組合中移除。如果元件的目標 ABI 修訂版本包含在不斷發展的組合中，系統就會將該元件視為與平台相容。

這個 RFC 說明元件和平台之間的 ABI 相容性。一般保證彼此的元件行為相容性 (尤其是如果元件是以不同但支援的 ABI 修訂版本建構) 不在此 RFC 範圍之內，且可能會做為 RFC-0002 中建議的未來工作的一部分，例如根據 ABI 修訂版本導入能力路徑。

條款

此設計在封裝元件的元件解析度程序中有多位演員彼此關聯。以下字詞將用於指稱具有指定角色的演員：

執行者 角色
解決動作 元件管理服務中，執行元件解析工作流程的動作。
解析器用戶端 元件管理服務中的用戶端實體，可透過 Proxy 向元件解析器傳送 FIDL 要求以解析元件。
元件解析器 提供 fuchsia.component.resolution.Resolver FIDL 通訊協定來解析元件的元件。注意：這個操作者不適用於內建解析器。
套件解析器 提供 fuchsia.pkg.PackageResolver FIDL 通訊協定來解析套件的元件。

注意事項

解析動作和解析器用戶端都屬於元件管理服務的一部分，但在設計中扮演著動力角色。

主要差異在於，解析動作無法區分封裝元件與未封裝元件。ABI 修訂版本必須在達到解析動作之前，從其資料來源解碼，且在封裝及未封裝的元件之間有所不同。

另一方面，目前每個元件解析器皆實作解析器用戶端，並針對其解析元件類型執行特定工作。

設計

目前狀態

本文件的設計初衷，是將封裝元件的目標 ABI 修訂版本取自其套件目標 ABI 修訂版本來源 (如 RFC-0135 定義)。

此設計可依據封裝元件的 ABI 修訂版本目前狀態滿足要求，無須假設未來元件的目標 ABI 修訂版本以及開發時程。

請參閱「ABI 修訂版本與非套件元件」一節，瞭解如何針對非封裝元件分別支援 ABI 修訂版本。

總覽

此 RFC 建議使用元件解析工作流程，包括從套件讀取和解碼元件目標 ABI 修訂版本、透過 FIDL 進行值的通訊，以及檢查 ABI 修訂版本是否與平台相容。

支援 ABI 的元件解析工作流程

圖 1：支援 ABI 的 ABI 元件解析工作流程

1. 元件解析器開啟並讀取套件 ABI 修訂版本檔案

封裝元件的目標 ABI 修訂版本目前與套件目標 ABI 修訂版本相同。ABI 修訂版本值會儲存在套件的 meta.far 中找到的檔案中。

雖然元件的目標 ABI 是以這種方式定義，但元件解析器「可能」使用套件解析器傳回的目錄 Proxy 讀取檔案。讓元件解析器直接讀取檔案的原因，是盡可能減少從套件目標 ABI 設定元件目標 ABI 的影響；可繪項目一節會討論此行為的特定缺點。

如果有檔案，元件解析器「必須」讀取及解碼 ABI 修訂版本，並在傳回給解析器用戶端的 FIDL 元件表示法中加入值。如果檔案不存在，則不會納入該值。 因此，元件解析器會延遲元件管理服務強制執行 ABI。

2. 在 fuchsia.component.resolution.Component 中新增 ABI 修訂版本欄位

將元件目標 ABI 修訂版本的獨立欄位導入元件 FIDL 表示法，其中 AbiRevision 是 uint64 值的別名：

sdk/fidl/fuchsia.component.resolution/component.fidl：

type Component = resource table {
...
   abi_revision AbiRevision;
}
...

技術債一節將討論當元件的目標 ABI 修訂版本納入 FIDL 中已代表的資料來源 (例如元件資訊清單) 時，這個欄位會如何成為多餘的。

3. 在元件管理服務中檢查 ABI 修訂版本狀態和相容性

解析器用戶端會將包含選用 ABI 修訂版本欄位的 FIDL fuchsia.component.resolution.Component 類型轉譯為元件管理服務表示法，並交出解決動作。

要檢查 ABI 修訂版本是否存在，以及其是否與 Fuuchsia 平台相容時，應在已解析元件的中繼資訊通過驗證後執行。

解析動作「必須」使用會公開 API 的程式庫，檢查指定的 ABI 值是否屬於平台支援的一組 ABI 值。這會判斷已解析元件的目標 ABI 修訂版本是否與平台相容。

元件管理員的設定旗標會指示解決動作對缺少的目標 ABI 修訂版本產生警示 (而非錯誤)，並在「實作」策略中用來啟用回溯相容性。同樣地，引進獨立的設定旗標以允許不相容的元件 ABI 修訂版本，對於沒有 ABI 相容性法規的不同版本測試元件可能很有幫助。

為什麼元件解析度的 ABI 相容性檢查？

元件管理服務中的呼叫端會解析元件網址，以便與建構的元件或其功能互動。將 ABI 相容性整合至元件解析度程序，可確保元件能夠以預期的方式與平台互動。

重新解析元件時，更新的 ABI 修訂版本應位於更新的元件資料之間。與其他元件中繼資料類似，ABI 修訂版本應等到元件明確更新後才會變更。

其他設計考量

處理套件元件中遺漏或不相容的目標 ABI 修訂版本

預期會出現目標 ABI 修訂版本的套件元件可能會發生錯誤，並可在下列任一時間點縮減元件的解析度：

  • 如果 ABI 修訂版本檔案存在，元件解析器無法將 ABI 修訂版本值解碼。
  • 解析動作無法將 FIDL 值解碼為 ABI 修訂版本資料類型。
  • 解決動作會發現 ABI 修訂版本不存在或與平台不相容，而元件管理服務設定旗標會將此情況表示為錯誤。

實際情況取決於使用者或元件管理服務是否觸發元件解析度，以及錯誤是否能直接傳回使用者，還是只能記錄下來以供可偵測。人體工學一節將詳細說明如何向使用者顯示警告和錯誤。

ABI 修訂版本和非套件元件

這個 RFC 不會定義非封裝元件 (例如網頁元件) 如何代表 ABI 修訂版本。系統會單獨考慮這類元件的 ABI 相容性意義，不會影響這項設計的初始推出，因此您可以選擇是否提供 ABI 修訂版本。

ABI 與子套件的相容性

頂層套件和子子套件 (如 RFC-0154 所導入) 應包含 ABI 修訂版本。如有任何這個 RFC，無須對子封裝元件進行特殊處理：由於每個子項子套件元件都已解析，因此也會依據圖 1 所述的相同元件解析工作流程來進行處理。但是，如果子封裝元件的目標 ABI 修訂版本與頂層封裝元件不同，且平台不支援該子封裝元件的 ABI 修訂版本，則子封裝元件會導致元件解析度失敗。這會與 RFC-0154 概述的子套件通常提供的可用性保證發生衝突。

ABI 相容性和內建解析器

啟動元件是由元件管理服務內建的啟動元件解析器解析。RFC-0167 引進了啟動元件的封裝：啟動元件解析器會從啟動檔案系統套件解析元件，格式與非啟動元件套件類似。

擷取及評估啟動元件的 ABI 修訂版本會遵循圖 1 所述的類似設計工作流程，但啟動元件和啟動套件解析器不是做為外部元件實作。

具體來說，啟動元件解析器需要進行的變更如下：

  • 啟動元件解析器會開啟，並讀取啟動檔案系統套件的 meta.far 中找到的雙修訂版本檔案。
  • 啟動元件解析器會將 ABI 修訂版本值加入傳回至解析動作處理常式的已解析元件表示法。

實作

此設計的實作分為兩個階段：

  1. 元件管理服務可讓您選擇元件目標 ABI 修訂版本。
  2. 元件管理服務必須指定元件目標 ABI 修訂版本。
    • 找不到 ABI 修訂版本檔案時，表示套件元件解析器錯誤。
    • 非封裝元件的 ABI 修訂版本會顯示。

元件管理服務的設定旗標可用來強制執行 ABI 要求及啟用階段 #2。

您可透過元件探索工具 (例如 ffx component) 檢查元件的目標 ABI 修訂版本。

效能

對效能沒有顯著影響。

人體工學

元件管理服務缺少或不相容的目標 ABI 修訂版本導致的元件解析度出現警告或錯誤。且應記錄所有元件解析警告和錯誤。

在某些情況下 (例如使用 ffx component)，使用者可能會啟動 FIDL 要求，該要求會解析元件，並在失敗時傳回描述性的 FIDL 錯誤回應。

在其他情況下，我們無法向使用者直接提供意見。舉例來說，功能轉送可能會因為元件解析路徑在從目標元件的路徑到提供能力的來源元件時發生中斷。這會以紀元關閉 fuchsia.io 能力管道，要求使用者讀取記錄，或可能使用診斷工具，取得關閉管道背後的原因。

回溯相容性

兩階段實作策略可確保元件解析度能繼續適用於尚未指定目標 ABI 修訂版本的元件套件。

系統為 FIDL ABI 修訂版本欄位產生的繫結固然可讓欄位成員選填，並讓我們能夠推出實作，而不會破壞尚未指定 ABI 修訂版本的元件。

回溯相容性行為受設定旗標管制，當缺少元件的目標 ABI 修訂版本或與平台不相容時，該旗標會指示元件管理服務傳回錯誤。

安全性考量

沒有已知的安全疑慮。

隱私權注意事項

沒有已知的隱私權疑慮。

測試

系統將使用現有的測試架構測試下列情境：

  • 用於讀取及解碼元件解析器中雙修訂版本檔案的單元測試。
  • 根據設定設定檢查 ABI 修訂版本存在/值的單元測試。
  • 元件解析器與解析器用戶端介面之間的整合測試。

說明文件

會介紹 https://fuchsia.dev 的說明文件，以便說明下列項目：

  • 元件目標 ABI 修訂版本的概念。
  • 元件目標 ABI 修訂版本的定義方式。
  • 如果元件的目標 ABI 修訂版本與平台不相容，會發生什麼情況。

此外，我們也會視需要撰寫原始碼文件。

缺點

元件解析器讀取套件中繼資料，以擷取元件的目標 ABI 修訂版本

元件的目標 ABI 修訂版本是由其套件目標 ABI 修訂版本衍生，並儲存在 meta.far 中 (儲存套件中繼資料)。或者，您也可以在元件中繼資料中定義元件目標 ABI 修訂版本，而元件解析器不會與套件中繼資料互動。

此外，由於套件中的所有元件都是從相同的單一值衍生目標 ABI 修訂版本，因此這會限制套件中的元件可以獨立發展。對於套件中具有不同更新頻率的個別元件維護者，這可能會造成問題。另一方面，子套件可用來將依附元件的目標 ABI 修訂版本分組和區分。

這會規範為何元件的目標 ABI 修訂版本設為其套件目標 ABI 修訂版本。這個 RFC 的「不明」是指日後如何定義元件目標 ABI 修訂版本，或是變更方式發生時間。然而，我們可能會瞭解，比起元件專屬的目標 ABI 修訂版本，更易於定義及導入套件層級目標 ABI 修訂版本，這需要投注更多的承諾與協調工作。此外，目前的策略包含 MVP，讓我們能夠開始使用元件目標 ABI 修訂版本，而不必等待日後在套件或元件中繼資料中定義這些修訂版本。

替代選項

檢查套件解析器中的 ABI 相容性

另一種設計可確認 ABI 修訂版本是在套件層級定義，而在元件解析度程序中發現 ABI 修訂版本檔案的第一個點就是套件解析度。相鄰的引數將延後導入元件層級的目標 ABI 修訂版本，直到在元件中繼資料定義 ABI 為止。

優點：

  • 解決 ABI 修訂版本定義的立即情況。

缺點：

  • 無封裝元件的解決方案。
  • 影響未來的工作計畫，使用元件管理員中的元件目標 ABI 修訂版本，例如根據 ABI 修訂版本控管能力路徑。
  • 將 ABI 控制項移至元件管理服務以外的外部元件。
  • 透過讓使用者可自行控制的方式，停用 ABI 強制執行來偵錯或測試的方式，就像在元件管理服務中新增設定標記一樣簡單。
  • 如果套件含有不相容的 ABI 修訂版本，但該版本已解決和下載，但未使用，可能會受到限製或以其他方式進行特殊處理。舉例來說，解決及擷取包含 ABI 修訂版本尚不支援目前執行平台支援的更新套件，仍應成功執行。

檢查元件解析器中的 ABI 相容性

元件解析器除了開啟及剖析 ABI 修訂版本檔案外，也可以檢查系統與系統的 ABI 相容性。

優點：

  • 如果系統不支援元件的目標 ABI，防止將元件傳回至元件管理服務。

缺點：

  • 將 ABI 控制項移至元件管理服務以外的外部元件。
  • 對使用元件管理服務中的 ABI 修訂版本影響日後的工作計畫，例如根據 ABI 修訂版本導入能力路徑。
  • 透過讓使用者可自行控制的方式，停用 ABI 強制執行來偵錯或測試的方式，就像在元件管理服務中新增設定標記一樣簡單。

元件管理員會在特定元件互動之前，檢查目標 ABI 相容性

元件管理服務可在對元件執行特定動作 (例如啟動元件或存取其中一項功能) 之前，檢查元件的目標 ABI 修訂版本是否受到支援。

優點：

  • 進一步說明應檢查 ABI 修訂版本的時機。
  • 可更有效地控制錯誤處理方式。

缺點：

  • 忽略元件的目標 ABI 是如何組成其介面的宣告的一部分，此設定會在元件解析度期間進行驗證。
  • 高維護成本，需要有人對應執行 ABI 檢查的情境瞭解。
  • 很容易從元件引入破壞、非預期或難以偵錯的行為，因為其缺少 ABI 相容性檢查。

從解析器用戶端開啟及讀取套件 ABI-修訂版本檔案

我們應避免將新行為導入元件解析器和 FIDL，藉此將這項臨時設計對元件目標 ABI 的影響降到最低，並實作最容易復原的解決方案。

優點：

  • 避免將新的 FIDL 欄位引進 fuchsia.component.resolution.Component，如果元件目標 ABI 修訂版本也包含在資料來源中，在 FIDL 中也代表該修訂版本 (例如元件資訊清單)，這可能會成為技術債。技術債一節會詳細說明這個情況。

缺點：

  • 直接從套件讀取檔案，違反解析器用戶端的抽象界線。這項作業必須在解析器用戶端中執行，而非解析動作，因為解析動作無法在封裝與非封裝元件之間建立區隔。
  • 我們無法判斷這項暫時修正的效期。

未知

未來將定義元件專屬目標 ABI 修訂版本的假設/方式/時機

系統為每個元件定義 ABI 修訂版本的時間表，讓同一套件中的元件擁有不同的目標 ABI 修訂版本。針對日後會儲存元件目標 ABI 修訂版本的資料來源，我們也並未做出承諾，也就是 ABI 是否會納入元件資訊清單中。

技術債

本設計不會假設元件目標 ABI 修訂版本日後將定義，並有產生技術責任的風險。

如果元件目標 ABI 修訂版本納入也具有 FIDL 表示法的來源 (例如元件資訊清單)，則 fuchsia.component.resolution.Component 的 ABI 修訂版本欄位成員將會變得多餘，應移除。這項技術債將受限於 fuchsia.component.resolution.Resolver 通訊協定及其使用該通訊協定的元件。

先前的圖片和參考資料

這項設計不考慮這個設計。