ebpf理解

简单记录下ebpf的个人理解。

结构

ebpf分为两部分。一部分是ebpf字节码代码，另外一部分是加载ebpf字节码的用户态程序。

ebpf字节码

字节码是只能使用bpf helper函数编写的代码。这个代码运行于内核中。
基于现有的tracing系统注入ebpf字节码，比如tracepoint，kprobe，raw_tracepoint等。这些根据注入点的不通这块将bpf程序进行对应的分类。每种类型有点差异，比如tracepoint类型的ebpf代码，获取函数参数按照指定的结构获取。而raw_tracepoint则不一样，它是放在一个数组里获取，而不用逐个关心每个参数怎么定义和数据结构对齐问题。

ebpf编程

ebpf编程有多种框架。比如bcc，bpftrace，基本libbpf，libbpf+core，coolbpf。

bcc

这个是python搞开发，ebpf代码是运行时才实时编译，需要在运行环境依赖kernel header，依赖clang llvm等环境。就导致部署太大，太麻烦，运行加载一次太慢，耗费部署环境cpu。基本商业无法实施。

bpftrace

这个是一个工具，像写脚本一样写bpf代码，就类似awk解释器和awk脚本的关系。这里bpftrace相当于解释器，它的代码称为.bt脚本。用bpftrace运行bt脚本。
这个就是灵活性差。只能脚本提供的能力，脚本不提供没法搞。

基本libbpf

这个基本意思是不使用btf相关，就用最基本的接口，避免btf文件的需求影响移植性。
这种就写ebpf字节码我们就用最基本的不涉及btf的helper函数，然后libbpf引用进来在用户态加载字节码。
这个基本实际是指考虑到移植性，在字节码编写的时候规避btf函数引用。
那怎么解决移植性，这里可以选择用下小节介绍的btf(core)。也可以选择sysmon的方案，将所有内核结构访问都当做普通指针加偏移量的方式访问，这个偏移量作为配置传递给ebpf使用，而不要搞指针形式访问，指针就代表了和内核数据结构关联了，就导致失去可移植性。

core

这个是指用btf方式访问，借助内核本身的btf能力，这个要求编译器版本clang大于12，要求libbpf封装了btf相关ebpf中使用的接口，并要求运行时存在vmlinux文件。
vmlinux文件在低版本是不自带的，最新内核会自带，这就需要低版本维护这个vmlinux。也是比较麻烦。比维护上个小节说的偏移量更麻烦点。因为偏移量好获取，但内核vmlinux比较困难，需要找到准确的内核发布时文件，进行生成vmlinux。当然Genbpf和龙西社区也都有维护，但商业用的时候客户的内核它不一定有，既维护的不全面。