平台可更新性后续步骤

Fuchsia 旨在实现更新。不过，它也仍在开发阶段。本部分重点介绍了一些正在进行或尚未开始的工作，这些工作将有助于提升 Fuchsia 的更改和更新能力。

整个界面中的版本控制和兼容性元数据

  • FIDL 支持可用性注释。
  • Fuchsia IDK 中尚未针对 C/C++ 头文件实现可用性注释。实现此功能后，下一步是将这些注释应用于 SDK 头文件。
  • FIDL API 摘要有助于检测破坏 API 的变更。目前，我们没有适用于 C/C++ API 的等效功能。通过将内容哈希与已知参考进行比较来检测潜在的破坏性更改，这会产生误检。例如，重新设置标头格式不会影响 API 或 ABI，但会错误地触发更改检测器。
  • 支持 vDSO 向后兼容性。例如，如果某个组件已知以旧版 ABI 为目标，那么 Fuchsia 可以在其地址空间中加载一个 vDSO shim，该 shim 会导出旧版 ABI 并调用最新的 vDSO ABI。
  • 目前还没有任何机制来指明用于构建给定软件包或组件的 Fuchsia SDK 版本。引入此类机制并使用它来注释预构建的软件包有助于检测不兼容性。

完成 Fuchsia ABI 到 FIDL 的迁移

虽然 Fuchsia ABI 主要是在 FIDL 中定义的，但仍有一些旧版 ABI 是以其他术语定义的，这些术语在可更新性方面没有相同的支持。

  • 虽然系统调用是在 FIDL 中定义的，但它们的一些输入和输出类型仍然在 Zircon 头文件中定义为 C 结构。例如，zx_object_get_info 在 FIDL 中定义，但其输出类型（buffer 参数）是一个对 FIDL 定义不透明的字节缓冲区，并以 zx_info_*_t C 结构体的形式进行格式化。
  • processargs 协议用于通过启动功能引导新创建的进程。引导消息的格式定义为 C 结构，应转换为 FIDL。

完成 Fuchsia SDK

基于 Fuchsia IDK 构建的 Fuchsia SDK 可用于开发 Fuchsia 组件，而无需检出 Fuchsia 的源代码或使用 Fuchsia 自己的 build 系统。不过，仍有一些开发者用例无法在树外实现。

弃用未列出的平台 ABI

平台表面的完整性应严格定义，并以 FIDL 等术语表示，以便通过版本控制和支持过渡等机制实现可更新性。目前，平台界面的一些方面不符合这些要求。

  • 某些树外组件测试框架通过指定平台组件的 fuchsia-pkg:// 启动网址来启动平台组件的测试替身。这些网址不具备可更新性。相反，树外组件会暴露于平台实现细节，例如包含实现特定平台功能的特定组件的特定软件包的名称。即使 SDK 或平台表面中未注册任何 API 或 ABI 破坏性变更，这些测试也经常会在 Fuchsia 平台和 SDK 修订版本之间中断。除了弃用现有用法之外，我们还应采取措施来防止这些问题再次发生。
  • Fuchsia 脚本层 (SL4F) 是一种用于测试的系统自动化框架。SL4F 由使用 JSON-RPC/HTTPS 协议的主机端测试驱动，该协议是根据现有系统的规范实现的。这一决定加快了大量连接测试的移植速度。不过，JSON-RPC/HTTPS 协议在可更新性方面不如 FIDL，因此无法为 ffx 插件提供相同的优势，而且它也没有架构。因此，今后我们不应再通过树外测试支持 SL4F 进行系统自动化，而应引入替代解决方案。

正式确定诊断合同

Fuchsia 支持多种诊断工具，用于了解系统的内部状态和排查问题。内部诊断本质上会公开实现细节，从而显示进程名称和层次结构等信息。

此信息在以下情况下非常有用：排查有缺陷的系统时，或在收集崩溃后的快照等信息时。在这种情况下，内部实现细节就非常重要。不过，诊断信息并不适合作为公开合同。

  • 运行时诊断信息（例如特定组件的 log 或 Inspect 属性）可以在运行时使用 fuchsia.diagnostics.ArchiveAccessor 功能（由 selector 指定）读取。选择器由组件别名、诊断层次结构路径选择器和属性选择器组成。Moniker 可能会公开平台实现详情，例如平台组件的拓扑和名称。层次结构和属性选择器也可能被视为实现细节，此外，它们没有可更新性机制。以下是基于 Fuchsia 的产品中在运行时使用诊断选择器读取系统诊断信息的树外组件的已知实例。这些组件会暴露给平台实现细节，并且在这些细节发生变化时经常会中断。Fuchsia 诊断的平台外部客户端应移植为使用严格定义的 FIDL 协议来精确读取所需信息，并且应限制开放式 ArchiveAccessor 功能供树外组件进一步使用。
  • 组件以不同的方式生成诊断信息，例如 Inspect 属性的内部层次结构或日志中的非结构化文本。大多数执行此操作的平台组件都不会保证此信息的特定架构。即使是具有结构和类型的 Inspect，也没有 FIDL 中提供的所有可更新性支持。因此，离线处理平台诊断信息（例如在 SDK 未提供的工具中或在特定于产品的信息中心内）必然会失败。
  • 跟踪和 mem 等性能工具会收集并公开性能信息，例如进程的名称及其相互关系。此信息有助于调查某些系统的性能，但它反映的是私有实现细节，而不是公共合约。

弃用旧版开发者工具

Fuchsia 开发者可以使用多种 SDK 工具，其中最重要的是 ffx 及其众多命令。新的 ffx 工具在主机和 Fuchsia 目标之间进行交互，其交互方式由 FIDL 定义，从而实现可更新性。不过，我们仍向不具备相同可更新性的树外开发者提供一些旧版工具。

  • 支持 SSH（例如使用 funnel 工具），并为主机提供类似于目标 Fuchsia 设备上的远程 root shell 的开发者体验。客户端可能会绕过预期的平台界面，例如直接观察、启动和终止系统进程。
  • 同样支持 SCP（通过 SSH 进行文件复制），并且提供对全局命名空间和可变文件系统的无限制访问，从而再次绕过预期的平台表面。
  • 某些开发者功能（例如）以旧版 shell 组件的形式（而非 ffx 命令）向开发者公开。这会使开发者接触到无法轻易更改的平台实现细节，例如软件包和组件的名称，并以人类可读的文本（而非类型化和结构化数据）来表达输入和输出。
  • 某些 ffx 命令（例如 ffx component）会公开内部实现细节，例如组件 moniker 和拓扑。这些功能旨在用于诊断和问题排查，而不是作为 API。

兼容性测试

您可以使用持续集成与静态分析工具和构建系统来检查 API 和 ABI 兼容性。此外，Fuchsia 兼容性测试套件 (CTS) 可以测试不同的受支持平台和 SDK 版本组合。这些测试可以将兼容性的概念从 API 和 ABI 扩展到还可确保保留重要的预期行为。

CTS 项目是新项目，覆盖率相当低。CTS 是一种纵深防御形式，因此增加覆盖率有助于确保兼容性符合预期，即使 CTS 覆盖率永远无法达到平台表面的 100%。

深入阅读