ebpf: bpf_prog_load() vs bpf_object__load()

Question

我已经有一段时间没有使用过libbpf了。现在，当我查看源代码和示例时，在我看来，现在所有的API都是围绕bpf_object构建的，而以前它是基于程序FD的(至少在面向用户的级别上)。我相信fd现在隐藏在bpf_object或类似的东西中。

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

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

Answer 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()组合。

但在构建下一个应用程序时，您可能会考虑到这一点。