本頁面由 Cloud Translation API 翻譯而成。

RFC-0188：元件 ABI 相容性

RFC-0188：元件 ABI 相容性
狀態	已接受
區域	元件架構
說明	偵測元件目標 ABI 修訂版本，並檢查平台是否支援該版本。
問題	95188
Gerrit 變更	695063
作者	caslyn@google.com
審查人員	abarth@google.com etryzelaar@google.com geb@google.com jsankey@google.com
提交日期 (年-月-日)	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 的設計文件已通過 Component Framework 團隊的設計審查。

什麼是元件 ABI 相容性？

ABI 相容性是指 Fuchsia 系統介面為元件提供的行為期望協議。RFC-0002 詳細說明瞭 ABI 修訂的影響，以及平台如何支援這些修訂。

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

本 RFC 說明元件與平台之間的 ABI 相容性。元件彼此的行為相容性一般保證 (特別是使用不同但支援的 ABI 修訂版本建構元件時) 超出本 RFC 的範圍，且可能是 RFC-0002 中建議的未來工作內容，例如根據 ABI 修訂版本導入能力路徑。

條款

設計會區分封裝元件的元件解析程序中的數個參與者。以下詞彙會用於指稱具有指定角色的參與者：

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

NOTE

解析動作和解析器用戶端都屬於元件管理服務，但在這個設計中扮演不同的角色。

重要差異在於，解析動作無法區分封裝元件和非封裝元件。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 修訂版本欄位

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

sdk/fidl/fuchsia.component.resolution/component.fidl:

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

「技術債」一節將說明，如果元件的目標 ABI 修訂版本已納入 FIDL 中代表的資料來源 (例如元件資訊清單)，這個欄位會如何變得多餘。

3. 在元件管理服務中檢查 ABI 修訂版本是否存在及相容性

解析器用戶端會將 FIDL fuchsia.component.resolution.Component 型別 (含選用 ABI 修訂欄位) 轉換為元件管理服務表示法，然後交給解析動作。

驗證已解析元件的中繼資訊時，應檢查 ABI 修訂版本是否存在，以及是否與 Fuchsia 平台相容。

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

Component Manager 的設定標記「可能」會將解析動作導向產生警告，而非針對缺少的目標 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 修訂版本檔案。
啟動元件解析器會在傳回給解析動作處理常式的已解析元件表示法中，加入 ABI 修訂值。

實作

這項設計分為兩個階段實作：

元件管理服務可讓您選擇是否要修訂元件目標 ABI。
元件管理服務會要求修訂元件目標 ABI。
- 如果找不到 ABI 修訂版本檔案，封裝元件解析器就會發生錯誤。
- 系統會顯示非封裝元件的 ABI 修訂版本。

元件管理服務的設定旗標可用於強制執行 ABI 規定，並啟用第 2 階段。

您可以使用 ffx component 等元件探索工具，檢查元件的目標 ABI 修訂版本。

效能

效能不會受到顯著影響。

人體工學

如果目標 ABI 修訂版本遺失或不相容，元件管理服務就會負責顯示元件解析度中的警告或錯誤。所有元件解析度警告和錯誤都應記錄下來。

在某些情況下 (例如使用 ffx component)，使用者可能會發起 FIDL 要求，解析元件並在失敗時傳回說明性 FIDL 錯誤回應。

在其他情況下，我們無法直接提供使用者意見回饋。舉例來說，如果從目標元件到提供功能的來源元件之間的路徑發生元件解析失敗，能力轉送可能會中斷。這會關閉 fuchsia.io 能力管道，並顯示墓誌銘，使用者必須讀取記錄或使用診斷工具，才能瞭解管道關閉的原因。

回溯相容性

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

針對 FIDL ABI 修訂版本欄位產生的繫結，本質上會將欄位成員設為選用，因此我們可以在不中斷尚未指定 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 修訂內容的定義。

缺點：

不適用於無套件元件。
影響日後使用 Component Manager 中元件目標 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 通訊協定和使用該通訊協定的元件。

既有技術和參考資料

這項設計未考量任何相關因素。