ebpf：bpf_prog_load() 与 bpf_object__load()

Posted 2023-03-06

【中文标题】ebpf：bpf_prog_load() 与 bpf_object__load()

【英文标题】：ebpf: bpf_prog_load() vs bpf_object__load()

【发布时间】：2021-04-22 02:04:49

【问题描述】：

我已经有一段时间没有使用libbpf了。现在，当我查看源代码和示例时，在我看来，所有 API 现在都是围绕 bpf_object 构建的，而之前它是基于程序 FD（至少在面向用户的层面上）。我相信fd 现在隐藏在bpf_object 之类的地方。

当然它保持向后兼容性，例如我仍然可以使用bpf_prog_load，但是使用libbpf 编写应用程序代码的首选方式似乎是通过bpf_object API？

如果我错了，请纠正我。谢谢！

【参考方案1】：

听起来对我来说大多是正确的。

低级包装器

如果我没记错的话，libbpf 中返回文件描述符的函数，主要定义在 tools/lib/bpf/bpf.c 中，一直都是非常低级的。例如bpf_load_program() 就是这种情况，它只不过是用于加载程序的bpf() 系统调用的包装器。此类功能仍然可用，但对于复杂的用例，它们的使用可能很乏味。

bpf_prog_load()

早就提供了一些更高级的功能。您提到的bpf_prog_load() 就是其中之一，但它返回错误代码，而不是文件描述符。它仍然可以作为使用库加载程序的一种选择。

bpf_object__*()

虽然我认为没有严格的指导方针，但我相信大多数示例现在都使用bpf_object__*() 函数。一个原因是它们提供了更一致的用户体验，围绕对象文件的操作进行组织，以提取所有相关的字节码和元数据，然后加载和附加程序。我认为，另一个原因是，由于这个模型比上一个版本更受青睐，这些函数对最近的 eBPF 特性有更好的支持，而bpf_object__*() 函数提供了旧的bpf_prog_load() 工作流不支持的特性。

Libbpf 进化

最后，值得一提的是，libbpf 的 API 目前正在接受一些审查，并且可能会重新设计as part of a major v1.0 release。您可能想看看公告中链接的work document：一些bpf_object__ 功能可能已被弃用，同样目前有一个提议：

弃用 bpf_prog_load() 和 bpf_prog_load_xattr() 以支持 bpf_object__open_mem, file() 和 bpf_object__load() 组合。

关于 v1.0 的发布还不确定，所以我现在不会太担心“弃用”——我不希望所有功能都被删除。但这是您在构建下一个应用程序时可能需要考虑的问题。