eBPF动手实践系列三：基于原生libbpf库的eBPF编程改进方案
内容提要
本文介绍了基于原生libbpf库的eBPF编程方案，包括准备环境、构建项目和改进方法。该方案具有更深的控制和灵活性，更好的学习和理解，更细粒度的依赖管理，以及更好的低版本内核适应性等优势。
延伸解读
三代eBPF编程方案的识别与选择
文章将C语言eBPF编程方案分为三代：第1代依赖bpf_load.c文件，已逐步废弃；第2代以原生libbpf库为核心，适合深入理解底层机制；第3代libbpf-bootstrap骨架方案封装度高，是当前主流。读者可根据项目需求选择：若追求控制力、学习价值或低版本内核兼容性，第2代方案更合适；若追求快速开发，第3代更便捷。
原生libbpf库的独特优势
相比libbpf-bootstrap等封装框架，直接使用原生libbpf库能提供更深的控制和灵活性，允许定制加载和管理eBPF程序与maps；有助于开发者理解eBPF内部工作原理；支持更细粒度的依赖管理，可指定libbpf版本；在低版本内核和发行版上兼容性更好。这些优势使其在需要精细控制或学习场景中仍有不可替代的价值。
hexdump改进方案解决分发难题
传统原生libbpf方案需同时分发用户态程序和bpf目标文件（如trace_execve.bpf.o），否则运行时报错。文章提出用hexdump命令将bpf目标文件转为十六进制文本，生成固定的skeleton.skel.h头文件，再通过bpf_object__open_mem从内存加载，从而将bpf字节码编译进可执行文件，实现单一文件分发。该方案还支持多实例编译，且不依赖libbpf-bootstrap的命名规则。
USDT与Uprobe跟踪的构建要点
文章将改进方案扩展到用户态跟踪，构建USDT和Uprobe项目。USDT需在模拟程序中用DTRACE_PROBE宏打静态点，并依赖sdt.h头文件；Uprobe则需计算函数偏移量或通过SEC宏指定。两者均支持在attach时或bpf代码中指定探针信息，推荐使用专用attach函数（如bpf_program__attach_usdt）以便灵活控制。BPF_USDT和BPF_KPROBE宏简化了参数获取，但需注意其内部实现。
Q&A
什么是基于原生libbpf库的eBPF编程方案？
基于原生libbpf库的eBPF编程方案是一种使用libbpf库进行eBPF程序开发的方法，具有更深的控制和灵活性，更好的学习和理解，以及更细粒度的依赖管理等优势。
如何准备eBPF开发的基础环境？
准备eBPF开发环境需要根据不同的Linux发行版安装相应的基础包和工具，例如在RPM包环境中使用'yum install'命令安装git、make、kernel-headers等，而在DEB包环境中使用'apt install'命令进行安装。
基于原生libbpf库的eBPF项目的目录结构是怎样的？
基于原生libbpf库的eBPF项目目录结构包括用户态代码、内核态bpf程序代码、头文件和一些helper文件，具体如./progs、./include和./helpers等。
使用hexdump命令生成skel.h头文件的好处是什么？
使用hexdump命令生成skel.h头文件可以简化eBPF项目的构建过程，并且使得最终的可执行文件不再依赖于外部的bpf目标文件，便于分发和管理。
libbpf库的向下兼容能力有什么意义？
libbpf库的向下兼容能力允许开发者在较低版本的内核上使用最新的libbpf库功能，从而提高了项目的兼容性和灵活性。
eBPF项目的Makefile解析有什么关键点？
eBPF项目的Makefile解析涉及多个Makefile文件的作用和编译过程的关键参数，主要包括如何通过主Makefile生成用户态和内核态程序的编译规则。
