问题描述
我有一段时间没有使用 libbpf。现在，当我查看源代码和示例时，在我看来，现在所有 API 都是围绕 bpf_object 构建的，而之前它基于程序 FD（至少在面向用户的等级）。我相信 fd 现在隐藏在 bpf_object 等中。
当然它保持向后兼容性，例如我仍然可以使用 bpf_prog_load，但是看起来使用 libbpf 编写应用程序代码的首选方式是通过 bpf_object API？
如果我错了，请纠正我。谢谢！
解决方法
对我来说听起来基本正确。
低级包装器
如果我没记错的话，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 版本尚无确定的消息，所以我目前不会太担心“弃用”——我不希望所有功能都被删除。但这是您在构建下一个应用程序时可能需要考虑的事情。