| RFC-0229: FIDL 2023 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 现有的 FIDL 线格式和交互模型（称为 FIDL 2023）将至少支持三年。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-08-29 |
| 审核日期（年-月-日） | 2023-10-11 |
摘要
本文档规定，现有的 FIDL 线格式和交互模型（以下简称 FIDL 2023）将至少支持三年。
设计初衷
FIDL 是多种内容的集合：语言、编译器、绑定、线格格式和交互模型。本文档关注后两者，因为它们对 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 团队会议中多次讨论了 2023 年 FIDL 的计划。
设计
此提案的目标是定义 FIDL 2023，并批准在本 RFC 获得接受后的至少 3 年内支持该规范的计划。
范围
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。与较新的对等方通信时，程序无法解码消息。这不违反《2023 年金融产品和服务法案》(FIDL)。
反例。我们更改了线格格式，以便对表使用稀疏表示法。程序无法使用此表示法解码消息。这违反了 FIDL 2023，即使我们使用标志对更改进行软过渡，也需要重新编译程序。
正面示例。我们向 FIDL 添加了一种新类型：
uint128。该程序无法解码此类型。这不违反《2023 年金融产品和服务法案》(FIDL 2023)，因为uint128不属于《2023 年金融产品和服务法案》(FIDL 2023) 的范畴。如果程序使用的协议不使用uint128，则不会出现问题。如果它们以 ABI 兼容的方式演变为在程序编译后使用uint128，也不会出现问题，因为此类值必然位于封装容器或新方法中。最后，如果在编译程序之前更改为使用uint128，则程序可以安全地解码uint128值。
正面示例。我们更改了互动模型，以允许服务器发起的双向方法。出于与上述
uint128示例类似的原因，此操作不会违反 FIDL 2023。
反例。我们更改了互动模型，以允许客户端向服务器发送墓志铭。这违反了 FIDL 2023，因为该程序可能会实现服务器，并且无法正确处理此类消息。
这些示例表明，线格格式和交互模型仍然可以更改，但更改必须是增量性的，并且需要用户选择启用（例如，选择在新 API 中使用 uint128 类型）。在 FIDL 2023 支持期间，未选择启用新功能的代码必须继续正常运行。
性能
我们承诺长期支持 FIDL 2023，这意味着我们无法通过更改线格格式来提升现有功能的性能。
工效学设计
此提案对人体工学没有影响。
向后兼容性
此提案完全与向后兼容性有关，因此我们将在整个文档中讨论它，而不是在本部分中讨论。
安全注意事项
如果我们发现需要进行不兼容更改的安全问题，可能会违背我们在 2023 年全面支持 FIDL 的承诺。
隐私注意事项
如果我们发现需要进行不兼容的更改才能解决隐私问题，则可能会违背我们在 2023 年全面支持 FIDL 的承诺。
测试
我们将继续使用 GIDL 测试线程格式，并使用 dynsuite 测试交互模型。我们还将投资扩大其覆盖范围，以增加对 FIDL 2023 功能和边界情况的覆盖。这有助于确保我们履行长期支持的承诺。
文档
我们必须更新 FIDL 线上传输格式规范。例如，除非另有说明，否则可以说所有内容均属于 FIDL 2023。
FIDL 绑定规范记录了交互模型的某些方面，但其中混杂了有关生成的绑定的结构和样式的准则。我们必须改为创建新的“FIDL 互动模型规范”。其中的每条语句都应有 dynsuite 测试作为依据。
缺点、替代方案和未知情况
缺点：更难改进 FIDL
此提案会使 FIDL 的演变和改进变得更加困难。例如，更改线缆格式将会成本更高。我们不仅必须使用标志执行软过渡（如前所述），还必须将旧读取路径保留更长时间，即使我们认为没有任何内容依赖于它。
替代方案：时长不同
此提案表明，我们会更加重视长期兼容性。大约三年的时间似乎比较合适。这比我们之前提供的任何兼容性期限都要长。但除此之外，没有太多其他信息。我们可以承诺其他年限。
未知：实际中的 ABI 兼容性
我们仍在了解 Fuchsia 上的长期 ABI 兼容性在实践中的表现。理想情况下，FIDL 可为开发者提供稳定的基础，以便他们不断改进应用和服务。过去，我们对 FIDL 进行了一些破坏性更改，以更好地支持可扩展性和兼容性，例如 RFC-0061：可扩展的联合体。FIDL 2023 是否具有上层提供长期兼容性所需的所有功能，还是缺少一些功能？
在先技术和参考文档
所有成功的操作系统都提供一定程度的长期兼容性。毫无疑问，Fuchsia 和 FIDL 也需要这样做。
长期支持版本的概念在开源软件中很常见。例如，Linux 内核会将某些版本指定为“长期”。