RFC-0188：元件 ABI 相容性

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

偵測元件目標 ABI 修訂版本，並透過平台檢查是否支援。
問題
蓋爾特變化
作者
審查人員
提交日期 (年-月-日)2022-06-27
審查日期 (年-月-日)2022-09-31

編輯此 RFC

編輯 RFC 中繼資料

摘要

本文件說明元件架構如何偵測元件的 指定 ABI 修訂版本，並確認該版本是否與 Fuchsia 平台相容 才能與元件互動

提振精神

應用程式與 Fuchsia 系統介面 因此，機構必須確保元件的 ABI 相容性與 不斷成長

建構元件時，我們期望平台會有一套行為期望 ABI，而且並未強制執行與 ABI 修訂的明確 ABI 合約 就會成為平台開發的一項限制。會有 建立元件時，目標鎖定不再是 ABI 修訂版本的時間 Ad Manager 使用者介面

元件架構可能導致元件無法以 不受支援的 ABI 修訂版本，同時確保平台支援 元件的目標 ABI。此 RFC 概述 元件架構會強制要求元件和 Fuchsia 平台。

相關人員

講師：

  • 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 建構的 ABI 時 修訂內容 - 不在此 RFC 規範範圍內，且可能為未來工作的一部分 RFC-0002 中建議使用的，例如依據 ABI 導入能力路徑 修訂版本。

條款

這項設計區分了元件解析度的多名發動者 封裝元件的程序下列字詞將用於表示 擔任不同角色的演員：

Actor (演員) 角色
解決動作 元件管理服務中用於執行元件解析度工作流程的動作。
解析器用戶端 元件管理服務中的用戶端實體，可將 FIDL 要求透過 Proxy 傳送至元件解析器來解析元件。
元件解析器 提供 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 修訂版本狀態和相容性

解析器用戶端會轉譯 FIDL fuchsia.component.resolution.Component 具有選用 ABI 修訂版本欄位的類型，以元件管理服務工具表示 送交解決

檢查 ABI 修訂版本是否存在，以及是否符合 解決問題的元件時，必須執行 Fuchsia 平台 中繼資料經過驗證。

解析動作「必須」使用會公開 API 的程式庫來檢查 指定的 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 階段

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

成效

不會對效能產生明顯影響。

人體工學

元件管理服務負責顯示元件中的警告或錯誤 解決方案。所有語言 應該記錄元件解決警告和錯誤。

在某些情況下，例如使用 ffx component 時，使用者 使用者可能會提出 FIDL 要求，以便解析元件並傳回 失敗時，請提供描述性的 FIDL 錯誤回應。

在其他情況下，使用者無法直接提供意見回饋。適用對象 例如，功能轉送作業可能會因 元件在目標元件的轉送路徑中無法解決元件問題 能力的來源元件這麼做會關閉fuchsia.io 要求使用者閱讀記錄 可能會使用診斷工具瞭解關閉管道的原因。

回溯相容性

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

為 FIDL ABI 修訂欄位產生的繫結本質會成為欄位 並允許我們推出實作 而不破壞尚未指定 ABI 修訂版本的元件。

回溯相容性行為受設定旗標管制， 如果元件的目標 ABI 修訂版本為 或無法與平台不相容

安全性考量

沒有任何已知的安全性疑慮。

隱私權注意事項

沒有任何已知的隱私權疑慮。

測試

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

  • 進行單元測試，以讀取及解碼元件中的 ABI 檔案 解析器。
  • 單元測試，根據設定檢查 ABI 修訂版本是否存在/值 可以管理叢集設定，像是節點 資源調度、安全性和其他預先設定項目
  • 元件解析器和解析器用戶端之間的整合測試 存取 API

說明文件

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 引進新的行為。

優點：

  • 避免推出新的 FIDL 欄位 fuchsia.component.resolution.Component，如果發生下列情況，可能會成為技術債 資料來源 ABI 修訂版本也會納入資料來源 像是元件資訊清單「技術債」部分 一起討論這個情境

缺點：

  • 直接從套件讀取檔案違反抽象界線： 解析為解析器用戶端這必須在解析器用戶端中執行，而非 解決動作，因為解決動作無法在 套件和非封裝元件
  • 我們不知道這項暫時修正措施的適用期間。

不明

未來何時定義特定元件目標 ABI 修訂版本/方式/時機

每個元件定義 ABI 修訂版本的時間 皆須具備不同目標 ABI 修訂版本，相同套件中的各個元件 未知。針對會儲存的資料來源，也沒有相關承諾 將元件鎖定 ABI 在未來的修訂版本是否會包含 ABI 是開放式問題

技術債

這項設計未假設元件目標 ABI 修訂版本會如何 未來的定義，而且可能引發技術債務。

如果元件目標 ABI 修訂版本包含在同時具有 FIDL 的來源中 例如元件資訊清單，然後是 ABI 修訂欄位 「fuchsia.component.resolution.Component」的成員將變多了 。這項科技債僅限於 fuchsia.component.resolution.Resolver 通訊協定及其使用的元件。

既有藝術品和參考資料

這項設計不包含任何考量項目。