ebpf开发API对比：bpf_prog_load()与bpf_object__load()的选型疑问

你的认知没有核心偏差，和libbpf的实际演进路径完全吻合。

• 老接口bpf_prog_load()：是libbpf最早实现的、对内核bpf()系统调用BPF_PROG_LOAD命令的最薄一层封装。设计目标就是完成单个独立eBPF程序的指令加载、内核验证、权限调整，最终返回程序对应的FD。这个接口不关联任何配套资源，你需要手动完成所有前置依赖的准备，完全不涉及map、全局变量、重定位等现代eBPF开发的核心流程。libbpf长期保留这个接口，纯粹是为了保证老版本二进制应用的向后兼容，从来不是新应用开发的推荐路径。
• 主流接口bpf_object系列：是libbpf针对完整CO-RE eBPF工作负载构建的全流程抽象。它以编译产出的标准eBPF ELF文件为输入，把程序、map、全局变量、BTF信息作为一个整体对象处理。你提到的“FD被封装在bpf_object内部”的判断是准确的：加载过程中所有程序FD、map FD、链接点FD的创建、跨模块关联都由libbpf自动完成，用户不需要从加载阶段就手动追踪管理这些句柄；当然这些FD并没有被彻底私有化，用户可以通过bpf_object__find_prog_by_name()、bpf_object__find_map_by_name()这类接口，随时从加载完成的对象里取出原始FD，用于自定义的attach、控制逻辑。

• 从开发效率看，走bpf_object__load()完成全量加载的流程，会自动覆盖map创建与初始化、程序与map的FD绑定、CO-RE重定位计算、全局变量赋值、跨程序的函数/尾巴表联动、BTF元数据挂载等十几项零散的底层操作；如果用裸的bpf_prog_load()接口实现同等功能，用户需要自己手写ELF解析、参数拼装、兼容逻辑，代码冗余度会提升一个量级，还容易出现各种版本兼容问题。
• 从生态适配看，从libbpf 1.0版本开始，官方所有示例、文档、配套工具链全部围绕bpf_object接口构建。新的eBPF程序类型、内核新特性的支持，也优先在bpf_object的加载链路里落地；老的bpf_prog_load()接口因为要保持参数稳定，迭代速度已经跟不上内核的功能更新节奏，很多新特性根本不会在这个薄封装接口上提供配套支持。

除非你要开发的是完全无依赖、无配套map、不需要CO-RE适配的极轻量独立eBPF程序，否则不推荐新的生产应用继续直接使用bpf_prog_load()作为加载入口。哪怕你需要做高度定制化的加载逻辑，也完全可以在bpf_object的抽象基础上做裁剪，而不是退回裸接口的开发模式。

内容的提问来源于stack exchange，提问作者Mark