代码之家 › 专栏 › 技术社区 › Mark

ebpf:bpf_prog_lad()与bpf_object__load()

ebpf bpf

0

Mark · 技术社区 · 4 年前

我没有使用 libbpf 过一会儿。现在,当我看源代码和示例时,我觉得现在所有的API都是围绕它构建的 bpf_object 而之前它是基于程序的 FD (至少在面向用户的层面上)。我相信 fd 现在隐藏在 bpf_对象 或诸如此类。

当然,它保持了向后兼容性,我仍然可以使用 bpf_prog_load 例如,然而,它看起来像是使用以下方式编写应用程序代码的首选方式 libbpf 是否通过bpf_object API?

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

0 回复 | 直到 4 年前

1

4

Qeole 4 年前

在我看来,这听起来基本正确。

低级包装

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

`bpf_prog_load()`

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

`bpf_object__*()`

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

Libbpf的演变

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

弃用 bpf_prog_lad() 和 bpf_prog_load_xattr() 赞成 bpf_object__open_{mem, file}() 和 bpf_object__load() 联合体。

关于v1.0版本还没有什么确定的,所以我现在不会太担心弃用——我不希望所有功能都被删除。但在构建下一个应用程序时,您可能需要考虑这一点。