| RFC-0229：FIDL 2023 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 当前的 FIDL 有线格式和互动模型（称为 FIDL 2023）将至少获得三年的支持。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-08-29 |
| 审核日期（年-月-日） | 2023-10-11 |
摘要
本文档确定，当前的 FIDL 有线格式和互动 模型（称为 FIDL 2023）将至少获得三年的支持。
设计初衷
FIDL 包含多种内容：语言、编译器、绑定、有线格式和互动模型。此 RFC 涉及后两项，因为它们与 ABI 兼容性有关。多年来，这两项都发生了显著变化。例如， 我们最近迁移了 RFC-0113：高效 信封的有线格式，并修订了 RFC-0138：处理 未知互动的互动模型。之所以能够进行这些更改，是因为我们了解所有使用 FIDL 的代码，并且可以更新所有代码。未来，随着平台的成熟，情况将不再如此。我们需要开始考虑长期 ABI 兼容性。
利益相关方
教员： abarth@google.com
审核人： hjfreyer@google.com、ianloic@google.com、sethladd@google.com、ddorwin@google.com
咨询对象： quiche@google.com、wilkinsonclay@google.com
社交化： 在编写此 RFC 之前，FIDL 团队会议多次讨论了 FIDL 2023 的计划。
设计
此提案的目标是定义 FIDL 2023，并批准从接受此 RFC 之日起至少三年内支持该计划。
范围
FIDL 2023 是指截至 2023 年 9 月的 FIDL 有线格式 和互动模型 的状态。FIDL 的所有其他部分均不在此范围内。
有线格式指定了 FIDL 消息在线上的编码和解码方式。 这包括互动模型中使用的事务消息，以及其他 通过 RFC-0120 API 进行独立编码和解码的用例。有线 格式已有相关文档，但有几点值得注意：
- 幻数是 1。对于任何其他幻数，解码都必须失败。
- 静态标志包括“v2 指示器”
0x0002。如果未设置此位，解码必须失败。 - 不得验证其他标志位。解码不得因当前未使用的静态标志或动态标志的值而失败。
互动模型指定了 FIDL 客户端和服务器的行为方式。例如，它包括 FIDL 对等互连方在无法解码收到的消息时必须关闭其通道端点这一事实。互动模型尚未 提供全面的文档（请参阅文档），但已在 FIDL dynsuite中进行了测试。
FIDL 2023 包含迄今为止所有 RFC 的有线格式和互动模型更改，特别是以下内容：
请注意，某些 RFC 尚未在所有绑定中实现。特别是， Go 和 Dart 绑定尚未针对 RFC-0137 进行更新。因此，它们并非完全符合 FIDL 2023。
支持
FIDL 2023 是 FIDL 有线格式和 互动模型的长期支持 (LTS) 版本。自此 RFC 获得批准之日起，它将至少获得三年的支持。
这并不妨碍向 FIDL 添加新功能。它只需要与 FIDL 2023 保持兼容。此外，如果我们添加任何新功能，这些功能不会自动成为 LTS 保证的一部分。
具体而言，假设有人编译了一个使用 FIDL 2023 的程序。在售后支持期限内，该二进制文件应能正常运行，前提是“正常运行”取决于 FIDL：
- 软件堆栈的其余部分（尤其是 Zircon 和组件框架）保持类似的长期兼容性；
- 它使用的 FIDL 协议保持不变或以 ABI 兼容的方式演变；
- 与其通信的对等互连方保持应用级兼容性。
以下是一些正面示例（此提案允许）和负面示例（不允许），用于说明 FIDL 2023 支持的含义。
正面示例。该程序使用包含结构体的协议。我们向此结构添加了一个字段，破坏了 ABI。该程序在与较新的对等互连方通信时无法解码消息。这不会 违反 FIDL 2023。
负面示例。我们更改了有线格式，以便为表使用稀疏表示法。该程序无法使用此表示法解码消息。 这违反了 FIDL 2023，即使我们使用标志软转换更改也是如此，因为这仍然需要重新编译程序。
正面示例。我们向 FIDL 添加了一个新类型
uint128。该程序无法解码此类型。这不会 违反 FIDL 2023，因为uint128不是 FIDL 2023 的一部分。如果程序使用的协议不使用uint128，则没有问题。如果它们以 ABI 兼容的方式演变，以便在程序编译后使用uint128，也没有问题，因为此类值必然位于信封中或新方法中。 最后，如果使用uint128的更改发生在编译程序之前，那么程序可以安全地解码uint128值。
正面示例。我们更改了互动模型，以允许服务器发起的双向方法。由于与上述
uint128示例类似的原因，这不会 违反 FIDL 2023。
负面示例。我们更改了互动模型，以允许客户端向服务器发送墓志铭。这违反了 FIDL 2023，因为该程序可能会实现服务器，并且无法正确处理此类消息。
这些示例表明，有线格式和互动模型仍然可以更改，但更改必须是附加的且选择性加入的（例如，选择在新 API 中使用 uint128 类型）。在 FIDL 2023 支持期间，未选择加入新功能的代码必须继续正常运行。
性能
我们承诺长期支持 FIDL 2023，这意味着我们无法通过更改有线格式来提高现有功能的性能。
工效学设计
此提案对工效学设计没有影响。
向后兼容性
此提案完全与向后兼容性有关，因此将在全文中讨论，而不是在本部分中讨论。
安全注意事项
如果我们发现需要进行不兼容更改的安全问题，可能会违反完全支持 FIDL 2023 的承诺。
隐私注意事项
如果我们发现需要进行不兼容更改的隐私问题，可能会违反完全支持 FIDL 2023 的承诺。
测试
我们将继续使用 GIDL 测试有线格式，并使用互动模型 使用 dynsuite。我们还将投入资金来扩大它们，以增加对 FIDL 2023 功能和边缘情况的覆盖范围。这将有助于确保我们履行长期支持的承诺。
文档
我们必须更新 FIDL 有线格式规范。例如，它可以说明，除非另有说明，否则所有内容都是 FIDL 2023 的一部分。
FIDL 绑定规范记录了 互动模型的某些方面，但它与有关 生成的绑定的结构和样式的指南混杂在一起。我们必须改为创建新的“FIDL 互动模型规范”。其中的每个语句都应由 dynsuite 测试提供支持。
缺点、替代方案和未知因素
缺点：更难改进 FIDL
此提案将使 FIDL 的演变和改进更加困难。例如，更改有线格式的成本会高得多。我们不仅需要使用标志执行软转换（与之前一样），而且还需要将旧的读取路径保留更长时间，即使我们认为没有任何内容依赖于它也是如此。
替代方案：不同的时间长度
此提案表明，我们更加重视长期兼容性。 三年时间大致合适。这比我们之前提供的兼容性时间更长。但除此之外，没有太多其他内容。我们可以承诺不同的年数。
未知因素：实际应用中的 ABI 兼容性
我们仍在了解 Fuchsia 上长期 ABI 兼容性在实践中的表现。理想情况下，FIDL 提供了一个稳定的基础，开发者可以利用它来演变应用和服务。过去，我们对 FIDL 进行了重大更改，以更好地支持可演变性和兼容性，例如 RFC-0061： 可扩展的联合。FIDL 2023 是否具有上层提供长期兼容性所需的所有功能，还是缺少某些功能？
在先技术和参考文档
所有成功的操作系统都提供一定程度的长期兼容性。 毫无疑问，Fuchsia（以及 FIDL）也需要这样做。
长期支持版本的概念在开源软件中很常见。例如，Linux 内核将某些版本指定为“长期”。