RFC-0188：元件 ABI 相容性

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

偵測元件目標 ABI 修訂版本，並檢查其是否支援平台。
問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)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 修訂版本引入能力路徑。

條款

此設計會在套件元件的元件解析程序中，區分多個參與者。以下是指稱具有指定角色的行為者時會用到的詞彙：

執行者 角色
解決動作 在元件管理服務中執行元件解析工作流程的動作。
解析器用戶端 元件管理服務中的客戶實體，可將 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 修訂版本，以及該版本是否與 Fuchsia 平台相容。

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

元件管理員的設定標記可指示解析動作，針對缺少的目標 ABI 修訂版本產生警告，而非錯誤，這將用於在Implementation 策略中啟用向後相容性。同樣地，如果您想在沒有 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-revision 檔案。
  • 啟動元件解析器會將 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-revision 檔案，進行讀取及解碼的單元測試。
  • 單元測試，用於檢查 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 修訂版本檔案

我們可能會盡量減少此暫時設計對元件目標 ABI 的影響，並避免在元件解析器和 FIDL 中引入新行為，以便實作最容易復原的解決方案。

優點：

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

缺點：

  • 直接從套件讀取檔案會違反解析器用戶端的抽象邊界。這項操作必須在解析器用戶端中執行，而非在解析動作中執行，因為解析動作無法區分已封裝和未封裝的元件。
  • 這項臨時性修正的有效期限目前尚未明確。

未知

日後是否/如何/何時定義元件專屬目標 ABI 修訂版本

目前尚未確定 ABI 修訂版本的定義時間表，因此同一個套件中的元件可能會有不同的目標 ABI 修訂版本。此外，我們也沒有承諾日後會使用哪個資料來源來儲存元件目標 ABI 修訂版本；ABI 是否會納入元件資訊清單，仍是未知數。

技術債

這項設計不會假設元件目標 ABI 修訂版日後的定義方式，也不會導致引入技術負債的風險。

如果元件目標 ABI 修訂版本包含在同時具有 FIDL 表示法的來源中 (例如元件資訊清單)，則 fuchsia.component.resolution.Component 的 ABI 修訂版本欄位成員就會變得多餘，因此應予以移除。這筆技術債只會影響 fuchsia.component.resolution.Resolver 通訊協定和使用該通訊協定的元件。

既有技術與參考資料

此設計未考量任何因素。