常见问题解答

以下是一些首次查看这些文档的人常见的问题和答案。希望这个问答部分能解答大多数疑惑。如果还有其他问题，请在 Cilium & eBPF slack 的 #ebpf 频道中联系，或者提交一个 GH 问题。

这个项目的目标是什么？

这个项目的目标是提供一个单一的、可搜索的、相互链接的 eBPF 相关信息资源。

这些文档适合谁？目标受众是什么？

这些文档（理想情况下）适合 eBPF 社区中的每个人，特别是：

• eBPF 程序作者（从初学者到高级用户）
• eBPF 库维护者
• eBPF 研究者/知识分子（那些需要或想要了解 eBPF，但由于各种原因不直接从事或使用 eBPF 的人）

项目的范围是什么？你会添加 XYZ 吗？

Linux 内核、与 Linux 内核一起维护的库（作为“参考实现”，特别是 iproute2、libbpf、libxdp），以及（当其成熟时）Windows 上的 eBPF。

为什么这个项目会启动？

在项目创建时，存在一些不同的 eBPF 资源，每个资源都讲述了拼图中的一部分。A 中可以找到辅助函数列表，B 中可以找到程序类型列表，但没有使用它们的描述。而在 C 中可以找到关于如何使用特定映射类型的教程，但没有关于如何入门 eBPF 的内容。

大多数资源不包括有关功能添加时间的信息，这在运行和分发基于 eBPF 的软件时非常重要。虽然这不能替代功能探测，但了解大致的内核版本兼容性在开发过程中可以是一个巨大的救星。

最后，实际上许多功能都有限制或相互作用，这些内容很少被记录。例如，关于哪些辅助函数适用于哪些程序的参考并不存在，因为没有资源同时记录了这两者。

为什么要单独创建一个项目？这些文档不应该属于内核树吗？

文档的有用性随着它覆盖某个主题的全面性而呈指数增长。项目越有用，就越能吸引更多人贡献。因此，贡献文档的人越多，项目覆盖的内容也会越广泛。这是一个积极的反馈循环，我们有很多内容需要覆盖，因此在开始时降低添加内容的摩擦是非常重要的。

虽然内核技术上是关于内核特性的文档的正确位置，但将更改提交到内核是一个漫长且充满摩擦的过程。这是 eBPF 存在的主要原因之一，它允许在没有内核贡献过程摩擦的情况下进行快速迭代。如果我们从内核开始这个工作，我们将无法保持与在树外所能维持的相同速度和积极反馈。没有这种速度，项目可能会在初始贡献者的精力耗尽后停止。

一旦这个项目证明了它的价值并获得了所需的支持，我们可以开始将文档逐步纳入内核树，只要它们有足够的时间成熟和修正。这一过程将如何进行以及需要多长时间仍待讨论。在此之前，这个项目将尽力提供优秀的 eBPF 文档。