RFC-0190：对 Syscall 的 FIDL 支持

RFC-0190：对系统调用的 FIDL 支持
状态已接受
区域
  • FIDL
  • 内核
说明

扩展 FIDL 以支持系统调用声明，并将接口的 FIDL 表示法作为我们的可信来源。
问题
Gerrit 更改
作者
审核人
提交日期（年-月-日）2022-07-08
审核日期（年-月-日）2022-09-22

修改此 RFC

修改 RFC 元数据

摘要

在系统调用（即 Fuchsia 接口定义语言 (FIDL) 目前无法定义它们。不过，这种缺乏支持会导致更严重的后果，而不是讽刺性的名称。“自带运行时”（以下简称“BYOR”）是我们的一个核心设计原则：它旨在简化在 Fuchsia 上使用任意应用框架和编程语言进行开发的流程。其中一个重要方面是，使运行时能够与其外部的用户空间系统无缝交互；FIDL 的无语言依赖 IPC 框架已可提供此功能。事实上，FIDL 是 Fuchsia 明确声明用于实现 BYOR 的工具，这绝非巧合。但启用运行时不仅仅意味着能够与其他进程通信。为了让任何运行时真正“运行”，必须允许它与内核通信，也就是说，进行系统调用。因此，FIDL 在根本上存在不足。

此 RFC 旨在解决这一问题，并为我们指明了实现 BYOR 的方向。具体而言，讨论内容包括

  • 扩展了 FIDL，以一流的方式编码和完全指定系统调用接口；
  • 使 syscall 接口符合正式模型对 FIDL 和 syscall 接口本身的影响；
  • 关于 FIDL 语言绑定如何使用这些信息以及它们反过来会向用户提供哪些新功能的预期；
  • 在维护系统调用接口和依赖于它的工具时，可以显著提升工作效率。

该文件是一份意向声明，而非完整的提案。我们希望在解决较小设计问题（在后续 RFC 中）的过程中，逐步形成更宏观的设计，从而为进行大量实验和仔细思考留出空间。在本部分，我们将确定预期结果、实现这些结果的大致路线图，以及在此过程中要遵循的原则和限制。

设计初衷

实际上，//zircon/vdso 下已经存在 syscall 接口的 FIDL 表示法；这就是 FIDL 库 zx，我们将在下文中将其称为“v1 (FIDL) 表示法”。不过，这种表示法不是第一类，并且会向尝试对其进行解释的绑定呈现大量的异端特性：即大量围绕特殊名称和注释的自定义注解和带外信号，以及假定会从中生成类似 C 的代码的框架。这些异常足以让只有一个后端（kazoo）能够解读它们。目前，kazoo 会根据这些定义为内核和 vDSO 生成基本逻辑，以及 Rust 系统调用外部函数接口（即FFI）封装容器、标准库中运行时的 Go 系统调用 FFI 封装容器，以及系统调用文档 Markdown 的部分。

因此，我们目前处于过渡状态，我们有一个对系统调用的准 FIDL 表示法，它非常重要，但无法用作实际的 FIDL（除了目前导出的某些基本枚举和类型别名之外），并且任何尝试进行解释的工具都会承担维护负担。虽然“我们已经开始做 X，并且已经完成了一半”并不能成为“我们要坚持完成 X”的充分理由，但它确实是一种同情性的动机，尤其是考虑到当前状态存在的以下问题。

不过，v1 FIDL 表示法只是部分可信来源；它包含系统调用定义，但对接口中的数据类型的统计不完整。数据类型的可信来源（存在大量重复）实际上是一组 C 头文件（即 <zircon/types.h>、<zircon/syscalls.h> 和 <zircon/syscalls/*>）。可解析 v1 表示形式的限制性质以及数据类型是在 C 中定义的事实，这两者都导致了实现 BYOR 以及接口本身的维护方面存在大量问题。

IDL 的动机

接口演变和偏移

如果系统调用接口发生更改，则此信息的所有不同分支也必须做出相应更改。这些分支包括

  • 特定于语言的系统调用封装容器。
    • 我们为 Rust 和 Go 提供了这些封装容器。请注意，Rust 封装容器是 kazoo 引入的薄 FFI 层之上的额外层，目的是让该语言的使用更符合惯例。
  • C 数据类型的语言专用类似项。
    • 我们为 Rust 和 Go 分别提供了这些选项。
  • 不涉及发出系统调用的用例，而是需要对系统调用接口进行更抽象的转换。
    • 我们的系统调用 Markdown 就是一个很好的例子；fidlcat 的接口合成也是一个例子。

除了一些由 kazoo 赞助的例外情况外，系统调用接口维护者和分支维护者都必须执行大量工作才能使这些内容保持同步并防止偏移：特别是，系统调用接口维护者必须知道所有分支的位置并记得更新它们，而分支维护者由于缺少可供机器读取的此类信息表示法，因此必须知道每个系统调用并明确枚举它们。

如果系统调用接口已完全编码在 IDL 中，则可以将这些分支重新构想为可以程序化生成所需信息的后端（因此不再是真正的分支）。在预期的后端中，没有一个特别复杂。稳定后，与现状相比，它们的“触碰”应该会大大减少，并会自动适应对 syscall IDL 的大多数更改（就像目前大多数 .fidl 文件更改不需要更新任何特定后端一样）。

C 蠕变

仅考虑 C 语言（在 C 头文件和 v1 FIDL 表示法的 C 转写拼写中），就可以轻松引入在 C 语言中合理但在其他语言中难以建模的系统调用签名和类型定义。以下是一些值得注意的示例：

  • 将缓冲区作为单独的指针和长度
    • 许多语言都使用单一类型来表示缓冲区，并且不一定能够以这种方式对其进行分解。此类语言的绑定还需要进一步的信号，才能将（指针、长度）对解读为组合缓冲区，而不是不相关的参数。
    • 如果缓冲区的指针和长度未在系统调用签名中并排显示（如 zx_vmo_read() 的情况），则建模会变得更加困难。
  • 未标记的联合
    • C 联合体被称为未标记的联合体，因为它们表示由其他类型组成的离散类型，但没有规范的方法来确定给定实例实际持有的类型（即“标记”）。标记联合体在其他语言中自然更常见（而且很有用），并且更有可能以单一概念的形式呈现。
    • 数据类型中的大多数（但不是全部）C 联合体实例都可以建模为标记联合体，因为它们在结构体中具有用作标记的相邻字段。不过，与上述缓冲区情况类似，没有任何信号表明这些事件之间存在关联，并且我们有非相邻标记的示例。
  • 通过类型擦除进行多路复用
    • 我们有许多系统调用会利用 void* 的类型不确定性来有条件地接受或返回不同的类型，从而有效地将多个函数签名复用到一个函数上。一个典型的例子是 zx_object_get_info(..., uint32_t topic, void* buffer, ...)，它会根据 topic 将 buffer 解读为任意数量的类型。在非 C 语言中对此进行建模可能非常困难：特别是，绑定还需要某种信号来指明签名的精确参数化方式，并且可能需要依赖于非规范化地为每个可能的实例化生成单独的函数。

这类 C 语言特性可能会大大增加在非 C 语言中表示系统调用接口的复杂性。如果改为在支持多语言的 IDL 的限制下工作，那么这种框架可以规避或最大限度地减少此类问题。

政策执行

我们希望强制执行与系统调用和数据类型相关的多项政策。通过 IDL 化，后端可以访问可供机器解读的此类信息表示法，届时，可以直接编写和维护用于政策强制执行的工具。

如需举例说明数据类型政策，请考虑以下以 C 语言表示的政策，这些政策源自我们在内核和用户空间之间共享数据的方式：

  • 固定大小的结构体或其动态大小的数组
    • 否则，数据的共享和解读会变得复杂。
  • 无间接
    • 数据需要完全可 memcpy 化，并且在构建数据时所用的地址空间之外的地址空间中可被理解；对源地址空间中数据的编码引用/指针可能会悬空，并且无法理解。（zx_iovec_t 是这方面的例外情况，需要特殊处理。）
  • 无嵌入句柄
    • 嵌入在布局中的手柄很容易被忘记关闭（或隐式“借用”）。
  • 无布尔字段
    • bool 在内存中占用 8 位，但只提供 1 位信息。为了提高空间效率，我们更倾向于使用位字段来传达这 1 位。
    • 偏执：C++ 标准允许未初始化的 bool 既不是 true 也不是 false！

将 FIDL 用作 IDL 的动机

来自单独 IDL 的之前课程

该平台之前引入了非 FIDL IDL：Banjo，用于表示驱动程序公开的接口。不过，后来我们发现这是一个错误的决定：Banjo 的维护负担大于其附加价值，驱动程序作者对它与 FIDL 之间的语法差异感到困惑，并且很难实现在 FIDL 和 Banjo 之间共享数据类型的自然愿望。自那以后，Banjo 已被废弃，我们正在大力改进 FIDL 以适应驱动程序用例，并将其用作替代方案。假设用于 syscall 规范的 IDL 有充分的动机，那么我们有理由预期用于此目的的新 IDL 也会遇到同样的陷阱。

绑定开发

FIDL 语言绑定依赖于进程间消息传递（例如通过通道），因此必须已经了解有助于实现此类通信的系统调用的子集。具体而言，他们已经在围绕这些系统调用管理 FFI 封装容器。如果这些系统调用以机器可读的形式呈现，则绑定将能够更轻松地构建和维护 FFI 层；但是，如果对系统调用的理解并非源自 FIDL，则绑定将分叉更多信息，或者最终会解读两个不同的 IDL IR（中间表示法）。

在数据类型方面，目前我们维护的库是与 FIDL 语言绑定分开的，用于表示这些类型，但同时也希望实现一定程度的互操作性。也就是说，我们自然希望这两者在使用方式上大致相同，这样代码就可以轻松地将它们搭配使用，而无需应对不兼容的拼写或样式决策。对于内核对象句柄和“zx_status_t”，我们希望它们的表示方式完全相同。最自然的实现方式是让绑定明确使用数据类型库，这正是目前的做法。因此，将这些内容视为分开的只是一种虚假的自由度，如果这些内容来自同一位置，对绑定维护者和用户来说肯定会很有益（详见下文）。

多语言特性

根据与 BYOR 的关系，FIDL 会努力使用可合理映射到任何可能的目标语言的抽象。这种框架可以防止系统意外地将系统调用接口偏向于特定语言（例如C）。

平台版本控制

FIDL 具有内置的平台版本控制支持，这将进一步简化系统调用演变，并以与 FIDL 其余部分相同的方式简化软过渡。

利益相关方

教员：

hjfreyer@google.com

Reviewers:

abarth@google.com、brettw@google.com、mcgrathr@google.com、surajmalhotra@google.com

咨询了：

azaslavsky@google.com、bprosnitz@google.com、mcgrathr@google.com、yifeit@google.com

社交：

此 RFC 中包含的高级概念已与 FIDL 和内核/vDSO 维护者进行过交流。

设计

如上所述，此文档未提供正确的设计。我们在此提出了该工作要实现的设计目标、原则和约束条件，以供审批。

目标

FIDL 库 zx 是系统调用的唯一可信来源

本 RFC 中列出的许多问题都与系统调用的形状、定义和文档的竞争真相来源有关。确保所有系统调用信息都直接通过简单的机器翻译从单一可信来源流向下游，就是为了解决这一问题。

SDK 中导出了 FIDL 库 zx

这是实现本 RFC 中提出的 BYOR 范式的前提条件。在此之前，相关的新设施仅适用于在该平台上工作的开发者。

系统调用规范使用纯 FIDL

最终，系统应仅使用 FIDL 语言规范中的功能来定义系统调用接口（可能会在过程中进行切换）。FIDL 后端不应需要带外信息才能对其进行解读（如果它位于 SDK 中，则肯定如此），并且其他 FIDL 代码应能够自由导入和使用其数据类型。

fidlc 强制执行系统调用政策

这里所说的“系统调用政策”是指构成“正确”系统调用声明的任何类型的检查，该检查完全取决于 FIDL 表示法中存在的信息。我们在上文列出了一些政策（虽然是用 C 语言术语）。

系统应在编译时强制执行系统调用政策。fidlc 已经负责验证系统调用声明是否语法正确，因此它也自然会判断该声明是否语义正确。我们希望确保后续验证会在某个时间点进行，但将其推迟到后续的任意验证后步骤会使工具集成变得复杂，并且会延长失败所需的时间，从而导致用户体验不佳。

系统调用绑定

FIDL 语言后端应提供 syscall 绑定：即 syscall 封装容器函数，以该后端的其他绑定的样式提供惯用的接口。具体而言，这意味着这些函数签名将采用库 zx 数据类型，因为这些绑定已表示这些数据类型。这为任何用户提供了与内核的规范化互操作性，同时也解决了原本需要将单独的绑定和系统调用发出逻辑拼凑在一起的尴尬局面。

如果我们选择不提供系统调用绑定，那么随着 zx 数据类型可作为常规 FIDL 导入，就会带来新的不便。假设一个 FIDL 客户端从某个通道中拉取了“zx_port_packet_t”，现在希望通过该通道以某种方式调用“zx_port_queue()”。如何实现这一点？如果调用方可以访问将该数据包类型的现有绑定作为输入的系统调用封装容器，则这很简单；但是，如果封装容器的数据包类型不同，则需要额外进行转换。无论此翻译逻辑位于何处，都会导致用户体验不佳，并产生大量尴尬的相互依赖关系。最好完全不进行翻译，并通过设计使相关代码能够互相理解。

鉴于 syscall 接口在特定内核对象周围具有提示性的面向对象特性，因此 syscall 绑定的自然选择是作为表示该内核对象的类的方法。不过，这由后端维护者自行决定。

尽可能减少工作量，实现系统调用演变

我们的目标是，系统调用演变基本上只需几个简单的步骤即可完成（至少在常见情况下是这样）：

第 1 步：更改 FIDL 系统调用声明，在达到平台 API 级别 X 时控制任何添加或移除操作；更新内核和 vDSO 以跟进更改。

非步骤：无需更新任何后端（例如用于生成 Markdown 的 fidldoc），因为每个后端都应在任何平台级别自动生成正确的系统调用绑定。

第 2 步：对于每个“代码库”，将目标平台 API 级别提升到 >= X，并更新其中包含的代码以使用新的系统调用绑定（或要求下游项目自行执行此操作）。

可能的步骤 3：如果在第 1 步中废弃了任何系统调用声明，那么在支持的最低平台 API 级别大于等于 X 后，请返回并将其移除。

原则

尽可能使用通用 FIDL 实用程序

随着新类型、语法和语义的引入，应优先考虑（或至少仔细考虑）对 FIDL 有一般实用价值的清晰概念。需要一系列新功能，并且已经显现出与非系统调用相关用例的协同效应（未来肯定还会有更多）。重叠越多，系统调用声明就越易于阅读。这还有助于熟悉 FIDL 工具中的相关支持，从而简化维护。

从长远来看，应避免针对为系统调用数据类型引入的新声明类型的使用施加 FIDL 语言限制，原因如下：

  • 如上文所述，我们希望规范使用“纯”FIDL，因此，将这些新结构降级为次要结构的任何做法在精神上和可能在实践中都会与之相悖；
  • 由于这些类型会出现在库 zx 中，因此每种语言后端都会大规模使用这些类型；
  • 它们的 zx 实例将以规范形式表示系统信息，并且此类信息应在任何传输中自由流动；
  • 关于系统调用数据类型建模的相关问题实际上并非仅限于系统调用；它们更广泛地适用于内存格式建模，并且可能有更广泛的应用。
  • 使用现有的不受限制的基本声明，许多 zx 数据类型都会是乏味的布局；如果这些类型中似乎任意的子集对其使用有例外限制，那将会很奇怪。

最大限度地减轻解释负担

系统调用声明 IR 应尽可能简单（不能再简单了），并且后端在对其进行解释时最好能够采用统一的逻辑（尽量减少特殊情况）。我们应努力为未来无数的后端作者简化解读流程，并减少他们可能需要应对的棘手问题。

愿意更改系统调用接口

我们会尽可能对系统调用接口进行建模。不过，有些内容可能极难建模。在这些情况下，我们应牢记尽量减少解释负担这一原则，谨防过度拟合，并愿意调整界面，使其更易于建模。

约束条件

对 vDSO 和内核的 FIDL 的操作性无知持续存在。

操作是指在系统调用签名或其实现注意事项中明确表达对 FIDL 的了解。这不包括在实现 vDSO 和内核时使用 FIDL 生成的代码的前景，这将（继续）具有巨大价值。

vDSO 的内部运作方式应对 FIDL 保持不透明。我们尝试对其接口进行建模，但这与向其模型构建者提供主题知识无关。让系统调用在操作上感知到 FIDL 无疑会违反抽象化原则，这会使这些系统相互依赖，但至少这是一个奇怪的想法，因为在没有 FIDL 的情况下，仍然可以发出系统调用（更不用说运行整个 Fuchsia）。这还会带来一系列新的系统版本问题。系统调用绑定只是为了在 FIDL 和 vDSO 之间提供桥梁。它们可以将系统调用作为与任何其他 FIDL 端点的通信呈现给用户，但这属于各个后端的前端选择。

完整规范

系统调用规范应为完整规范，即它会编码接口的完整语义，并且通常包含我们的系统调用依赖后端（包括生成文档的后端）通常需要的所有机器可读信息。

线上系统调用数据类型与其 C 表示法一致

假设您希望将内存格式编码为 FIDL。这项注意事项不仅限于 C vDSO API 预期的系统调用参数，还可能包括寄存器布局、网络数据包头和 ZBI 格式等任何内容。此类数据的使用方自然希望以定义的格式使用这些数据，因此只有在有方法将其绑定转换回正确的格式时，FIDL 编码才能以特定语言使用。语言绑定已支持对可在 FIDL 中定义的任何类型编码和解码 FIDL 线格式。如果该内存格式的特定按位布局与 FIDL 线格式完全匹配，那么通过在 FIDL 中描述每个布局，每个语言绑定也可以支持该格式，而无需执行任何特定于新格式的工作。

基本 FIDL 类型的线格格式与其自然 C 同类的布局不谋而合（并且不太可能发生变化），这绝非巧合：目前，这些类型是整数和布尔基元、枚举、位、数组和结构体。为简单起见，并为了让系统调用绑定能够以规范的方式呈现预期的 vDSO 输入，我们建议仅将数据类型的建模限制为这些 FIDL 类型。这尤其禁止使用包含非线性数据的类型，以及根据上述操作无知约束条件的 FIDL 专用标头。

这里，矢量代表一个有趣的案例和可能的异常。系统调用接受以缓冲区形式提供且具有单独提供的长度的动态大小数据数组。这种情况可以通过矢量绑定进行自然建模。但是，向量的线格格式为 (length, pointer)，而系统调用期望缓冲区参数为 (pointer, length)。（前者的指针也具有 void* 类型，而后者的指针可以是指向特定类型的指针。）我们可以更新 syscall 接口中的所有缓冲区参数，以便上述原则适用于矢量，但将此情况保留为定义性例外情况似乎是合理且谨慎的做法。在所有位置交换这些参数所涉及的工作量非常大，而且风险很大；这样做的好处是，可以避免为交换两个参数而对矢量进行特殊处理序列化，从而最大限度地减少认知负担。（我们还有 zx_iovec_t，它本身就是一个类似矢量的类型。）

实现

  • 对于每项新功能，FIDL 和内核/vDSO 维护人员将协作并生成 RFC。该功能获得批准并实施后，v1 表示法将更新为使用该功能。

  • v1 表示法的特性将合并到一个自适应层中，以便在其上编写更多后端，而无需了解系统调用最初是如何在 FIDL 中编码的。实现这一点的一种简单方法是将其 IR 转换为另一个 IR，该 IR 近似于在我们完成语言扩展后 fidlc 会生成的最终 IR；这还可以作为一个风险较低的测试场地，以便逐步确定后者的 IR 应如何构建。随着 v1 表示法更新为使用新的 FIDL 功能，自适应层可能会被逐渐淘汰，最终被删除。这样一来，各种后端就可以在系统实际正确提供 syscall 声明支持之前继续进行声明支持。

  • 系统会根据需要谨慎更新系统调用接口，以满足新的 FIDL 建模方式。每项此类更改都将基于 RFC 进行。

  • 系统会生成 syscall C 头文件。

  • fidldoc 将扩展为从 FIDL 库 zx 生成系统调用文档。

  • 语言后端将扩展为生成系统调用绑定；代码将迁移为使用这些绑定。

  • SDK 中将导出 FIDL 库 zx。

  • 以不依赖于 FIDL 的方式提供系统调用封装容器和数据类型的独立库将被废弃。

性能

此提案没有固有的性能影响。它会将各种语言现有系统调用发出逻辑的性能注意事项忠实地转移到其关联的 FIDL 语言后端。虽然在实践中，鉴于系统调用数据类型的表示法与我们现已维护的语言绑定之间的一致性（rust 绑定已使用 fuchsia-zircon-types crate 和 C++ libzx 的 LLCPP 绑定），为当今的语言后端引入系统调用绑定很可能意味着只需进行表面修改即可生成现有的代码。

我们将发布后续 RFC，以便在此计划的背景下提出具体更改；如果有，相关性能注意事项将在这些论坛中讨论。

工效学设计

改进：

  • 单一且完全记录的可信来源。
  • 更清晰、更轻松地实现 BYOR。
  • 更轻松地进行系统调用演变和维护
  • 自动强制执行的系统调用政策。
  • 现有的依赖于系统调用的后端变得更易于维护（例如 zxdb 和 fidlcat），并且许多新的有价值的后端变得易于编写（例如，用于为模糊测试引擎生成系统调用说明的后端Syzkaller），或用于生成系统调用 MSan（内存清理器）检查的模块。
  • 语言绑定和系统调用封装容器之间没有集成问题。

回归：

  • 系统调用绑定将被视为正常的 FIDL 生成的源代码，因此与当今的等效库相比，它们的易读性可能会降低，并且更难理解。不过，生成的源代码缺少文档或可读性不佳并不是特有的系统调用问题，我们应该努力以更广泛的方式解决此问题，而不受此工作的影响。
  • 现有语言绑定需要承担更多责任，并且代码面更大，出错的可能性更高。

向后兼容性

我们将发布后续 RFC，以便在此计划的背景下提出具体更改；如果有，相关的向后兼容性注意事项将在这些论坛中讨论。

安全注意事项

如上所述，此提案将为在我们的清理程序和模糊测试基础架构中更轻松地维护系统调用支持铺平道路。

我们将发布后续 RFC，以便在此计划的背景下提出具体更改；如果有，相关安全注意事项将在这些论坛中讨论。

隐私注意事项

我们将发布后续 RFC，以便在此计划的背景下提出具体更改；如果有，相关隐私保护注意事项将在这些论坛中讨论。

测试

在此次计划的实施过程中，我们将引入的大部分（如果不是全部）内容都应纳入现有的子系统和测试体系：

  • 与现有功能一样，新的 FIDL 功能将通过针对 fidlc 和每个相关后端的常规金标准测试进行测试
  • 给定语言的系统调用绑定将取代我们目前手动维护的等效系统调用封装容器库，因此，任何被认为适用于后者的测试都可以更新为使用前者。具体而言，我们可以更新 Zircon 的核心测试以使用我们的 C++ 系统调用绑定，并且我们在 //src/lib/zircon/rust crate 中的单元测试也可以更新为使用 Rust 系统调用绑定。
  • 此外，在此过程中修改或重写的任何其他后端（例如 fidldoc）的现有测试体系都将得到延伸或移植。

文档

新的 FIDL 功能将与当前功能以相同的方式记录，从而扩展该语言的官方规范。此外，我们将更新对语言绑定的预期，以纳入系统调用绑定的提供。

缺点、替代方案和未知情况

现状充满了各种负担：它会给系统调用带来过多维护负担，使其缺少我们认为在维护其他公共接口时必不可少的护栏；它不利于任何将系统调用接口作为输入的软件，如果 Fuchsia 要取得成功，这将被视为无限数量；它包含我们基本系统接口的无线分支，其中包括自己的文档；它与核心平台愿景 (BYOR) 不一致；它会阻碍以规范形式跨进程共享基本系统信息（因为 zx_* 类型未在 FIDL 中表示）。

其中有很多不良现象，而且根深蒂固，这意味着需要付出大量努力才能解决问题。实现此提案的目标将是一条漫长而坎坷的道路。FIDL 和内核/vDSO 维护者需要进行大量的持续投资，这些投资有时可能会对所有人造成干扰。如果未保持合理的节奏，可能会导致（另一个）旷日持久的过渡状态。对系统调用接口进行必要的更改可能会导致后续出现一系列问题。

转入最终状态的开销应仅限于官方 FIDL 工具中持续提供的系统调用支持，这应该相对有限且无需太多人工干预。有人可能会认为，fidlc 中的支持是必然会被废弃的，因为我们最终需要某种方式来可靠地理解和强制执行完整的系统调用语义（即使在这种情况下，在这方面进行冗余也是有价值的）。此外，在我们的语言后端生成系统调用绑定的逻辑应该相当于从 IR 编码的签名到源代码声明的简单机器翻译、线编码的应用，以及对已维护的 FFI 层的使用，以调用 vDSO。

替代选项：

  • 不执行任何操作。
    • 我们已经到了无法忍受的地步，因此提出了这个影响深远的提案。如果不采取行动，现有的维护负担将会持续存在，而且随着越来越多的新开发者尝试移植现有软件和运行时，这种负担只会随着时间的推移而加重。
  • 我们投资于新的 IDL。
    • 我们甚至可以放弃与 FIDL 的互操作性，而只追求接口的静态、可供机器读取的描述，这样我们仍然可以为平台带来很大价值。
    • 不过，Banjo 的历史经验值得借鉴，该平台可能不希望重蹈覆辙。
  • 不要尝试更改系统调用接口以对其进行建模。
    • 虽然可行，但这会违背上述许多设计目标和原则，并会导致这些目标和原则要解决的问题无法得到解决。

在先技术和参考文档

  • GNU Mach 微内核使用相同的 IDL 来定义其系统调用和进程间通信（请参阅此处的 .def 文件，并参阅此处的编译器 (MIG)）。此系统至今仍在 Darwin 中使用。

  • //zircon/vdso v1 表示平台首次尝试将系统调用转换为 FIDL。

  • Banjo 是非 FIDL 平台 IDL。