RFC-0188：组件 ABI 兼容性

RFC-0188：组件 ABI 兼容性
状态已接受
领域
  • 组件框架
说明

检测组件目标 ABI 修订版本并检查其对平台的支持。
问题
Gerrit 更改
作者
审核人
提交日期（年-月-日）2022-06-27
审核日期（年-月-日）2022-09-31

修改此 RFC

修改 RFC 元数据

摘要

本文档将介绍组件框架将如何检测组件的 目标 ABI 修订版本，并检查它是否与 Fuchsia 平台兼容 然后再与组件交互

设计初衷

作为应用和 Fuchsia 系统接口 不断发展，需要通过 平台发展壮大

组件根据平台的一组行为预期构建 并且不与 ABI 修订版本强制执行明确的 ABI 协定， 预期会成为平台开发的一个制约因素。会有 以不再有效的 ABI 修订版本为目标构建组件的时间 提供支持

组件框架可能会阻止执行以 不支持的 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 高于平台，则视为该组件与平台兼容 这个不断演变的集合中包含

此 RFC 介绍了组件和平台之间的 ABI 兼容性。 关于以下组件的行为兼容性的一般保证： 彼此 - 尤其是在使用不同但受支持的 ABI 进行构建时 修订版本 - 不在 RFC 的涵盖范围内，未来可能会纳入这些内容 RFC-0002 中建议的设置，例如根据 ABI 引入功能路由 修订版本

条款

设计对组件分辨率中的多个操作者进行了说明 封装组件的流程以下术语是指 具有指定角色的演员：

演员 角色
解决操作 组件管理器中用于执行组件解析工作流程的操作。
解析器客户端 组件管理器中的客户端实体，将 FIDL 请求代理到组件解析器以解析组件。
组件解析器 一个组件，提供 fuchsia.component.resolution.Resolver FIDL 协议以解析组件。注意：此执行器不适用于内置解析器。
软件包解析器 提供 fuchsia.pkg.PackageResolver FIDL 协议以解析软件包的组件。

注意

解析操作和 resolver-client 都是组件管理器的一部分， 在这种设计中发挥了决定性作用。

一个重要的区别在于，解析操作无法区分打包的 从非打包组件中移除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 是以这种方式定义的，但组件解析器可以 使用软件包解析器返回的目录代理读取文件。通过 组件解析器直接读取文件的理由是尽量减少 从软件包目标 ABI 设置组件的目标 ABI 的影响； 缺点部分讨论了 行为

如果该文件存在，组件解析器必须读取和解码 ABI 并将值包含在返回到 解析器客户端如果该文件不存在，则不包含该值。 因此，组件解析器会将强制执行 ABI 操作推迟到 组件管理器。

2. 向 fuchsia.component.resolution.Component 引入了 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 修订版本，以及它是否与 解析的组件的 元信息通过验证。

解析操作必须使用一个公开 API 的库， 给定的 ABI 值属于平台支持的一组 ABI 值。这个 将确定已解析组件的目标 ABI 修订版本是否 与平台兼容。

组件管理器的配置标志可以指示解析操作生成 警告，而不是针对缺失的目标 ABI 修订版本的错误， 用于在“实现”策略中实现向后兼容性。 同样，引入单独的配置标志以允许不兼容的组件 ABI 修订版本可能有助于针对不同 build 测试组件 且不受 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 修订版本，并且 平台不再支持该子打包组件的 ABI 修订版本， 那么子打包的组件将无法进行组件解析。这会 与子软件包通常提供的可用性保证相冲突， （如 RFC-0154 所述）。

ABI 兼容性和内置解析器

启动组件由启动组件解析器解析 组件管理器中RFC-0167 中引入了 启动组件打包：启动组件解析器 从 bootfs 软件包中构建，其格式与非启动组件软件包类似。

检索和评估启动组件的 ABI 修订版本遵循 图 1 所示的设计工作流程（启动组件和 启动软件包解析器未作为外部组件实现。

具体而言，启动组件解析器所需的更改包括：

  • 启动组件解析器会打开并读取在 bootfs 软件包的 meta.far。
  • 启动组件解析器将 ABI 修订版本值添加到已解析的 组件表示法。

实现

此设计分两个阶段实现：

  1. 组件管理器使组件目标 ABI 修订版本成为可选项。
  2. 组件管理器使得需要组件目标 ABI 修订版本。
    • 如果未找到 ABI 修订版本文件，则会发生打包组件解析器错误。
    • 表示非打包组件的 ABI 修订版本。

组件管理器的配置标志可用于强制执行 ABI 要求， 启用阶段 2。

可以通过组件发现来检查组件的目标 ABI 修订版本 工具，例如 ffx component。

性能

对性能没有明显影响。

工效学设计

组件管理器负责显示来自组件的警告或错误 针对目标 ABI 修订版本缺失或不兼容而解决。全部 组件解析警告和错误。

在某些情况下（例如使用 ffx component），最终用户 用户可以发起 FIDL 请求，以解析组件并返回 失败时的描述性 FIDL 错误响应。

在其他情况下，用户无法直接向用户提供反馈。对于 例如，功能路由可能会被 在从目标组件到之间的路由路径上的组件解析失败 提供相应功能的来源组件。此操作将关闭fuchsia.io 带有上一首记号的功能通道，需要用户阅读日志或 可能使用诊断工具获取关闭渠道背后的原因。

向后兼容性

两阶段实施策略可确保组件解析持续 适用于尚未指定目标 ABI 修订版本的组件包。

为 FIDL ABI 修订版本字段生成的绑定本身会使该字段 成员可选，并且可让我们部署实现 而不会破坏尚未指定 ABI 修订版本的组件。

向后兼容行为受配置标志的限制，该标志会将 如果组件的目标 ABI 修订版本为 缺失或与平台不兼容。

安全注意事项

没有已知的安全问题。

隐私注意事项

没有已知的隐私问题。

测试

现有测试框架将用于测试以下场景：

  • 用于读取和解码组件中的 abi-revision 文件的单元测试 解析器
  • 用于根据配置检查 ABI 修订版本是否存在/值的单元测试 设置。
  • 组件解析器和 resolver-client 之间的集成测试 界面。

文档

将推出有关 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 兼容性检查。

从 Resolver-Client 打开并读取软件包 ABI-Revision 文件

我们可能希望尽量减少这种针对组件目标的临时设计的影响 ABI 并实施最容易撤消的解决方案，即避免使用 为组件解析器和 FIDL 引入了新行为。

优点：

  • 避免在 Cloud Storage 中引入新的 FIDL 字段 fuchsia.component.resolution.Component，否则可能会成为技术债务 组件目标 ABI 修订版本也会包含在数据源中 以 FIDL 表示，例如组件清单。Tech Debt（技术债务）部分： 对此场景进行更详细的说明。

缺点：

  • 直接从软件包中读取文件会违反 解析器客户端此操作必须在 resolver-client 中执行，而不是 因为解决操作无法区分 封装组件和未打包组件。
  • 这种临时修复将会持续多长时间。

未知

如果/如何/何时/未来会定义特定于组件的目标 ABI 修订版本

将为每个组件定义 ABI 修订版本的时间轴，从而允许 具有不同目标 ABI 修订版本的组件， 未知。对于将存储数据的数据源，也不提供 将来会进行组件目标 ABI 修订版本；是否会包含 ABI 是一个开放式问题。

技术债务

此设计没有假定组件目标 ABI 修订版本将如何 且存在引入技术债务的风险。

如果组件目标 ABI 修订版本包含在也具有 FIDL 的来源中 表示形式（例如组件清单）以及 ABI 修订版本字段 “fuchsia.component.resolution.Component”中的成员将成为冗余成员， 应移除。此类技术债务将仅限于 fuchsia.component.resolution.Resolver 协议以及使用该协议的组件。

先验技术和参考资料

未考虑此设计。