Linux内核BTF与CO-RE深度实战：可移植BPF程序的架构原理与生产实践

1 阅读 0 评论 0 点赞

引言

BPF（Berkeley Packet Filter）技术在过去五年经历了从简单包过滤到通用内核可编程引擎的惊人蜕变。然而，BPF程序长期以来面临一个棘手的可移植性难题：针对某个内核版本编译的BPF字节码很难在另一个内核版本上直接运行，因为内核数据结构字段的增删、类型和偏移量会随着版本迭代而改变。BPF Type Format（BTF）的引入以及基于它构建的 Compile Once – Run Everywhere（CO-RE）方案，从根本上解决了这一困境。今天，从 Kubernetes 的网络层（Cilium）到可观测性工具（bpftrace、Parca），再到安全沙箱（Tetragon），CO-RE 已成为现代BPF生态的事实标准。本文将深入 BTF 的组织结构、CO-RE 的重定位机制、libbpf 的实现原理、以及生产环境下的工程实践细节。

1. BPF可移植性问题的由来

1.1 传统BPF编译模式的困境

在内核 4.x 时代，BPF程序的编译和加载采用"本地编译"模式：开发者需要获取目标机器的内核头文件（kernel headers），在目标机器上或与被目标机器相同内核版本的环境下编译BPF字节码。这种模式存在根本性问题：

头文件依赖：每个部署目标都需安装 kernel-headers 包，在容器化环境中极难维护，且不同发行版的头文件位置不一致。
内核版本锁定：针对不同内核版本需要编译不同的BPF对象文件，大规模集群中的内核版本分布可能横跨数十个不同版本。
结构体偏移硬编码：BPF程序通过 bpf_probe_read() 直接读取内核内存，字段的偏移量在编译时硬编码到指令中，一旦内核版本变化，所有偏移量失效。
CKS/容器兼容性：在 Kubernetes 等容器编排环境中，节点内核版本不受应用开发者控制，无法假设目标内核配置。

1.2 曾经的解决方案及其局限

社区曾尝试多种解决方案：

BCC 运行时编译：目标机器上安装 LLVM/Clang，运行时动态编译。工具链庞大（LLVM 约 1GB），启动慢，且需要内核头文件或 BTF 原始数据支持。
预编译多版本分发：为常见内核版本预编译 BPF 字节码并打包分发。维护成本极高，无法覆盖所有可能的内核配置变体。
用户态重定位代理：在用户态加载程序时根据当前内核结构体布局修改字节码。实现复杂，性能开销大。

这些方案都不够优雅，直到 BTF 的出现提供了一条全新的路径。

2. BTF（BPF Type Format）：类型的自描述元数据

2.1 BTF 的诞生背景与设计目标

BTF 最初由 Facebook 工程师为 BPF 可移植性问题设计，Linux 5.1 正式合入内核，core 实现仅约 7000 行代码。其设计目标是让 BPF 程序在编译时记录结构化信息，在加载时根据目标内核的 BTF 信息进行动态重定位。

2.2 BTF 数据格式详解

BTF 数据嵌入在 ELF 文件的 .BTF 和 .BTF.ext 两个 section 中，其内部组织为 "类型图"（Type Graph）：

─────── ELF Object (.o) ────────────────────────────
                                                      
  .BTF section (类型元数据)                           
  ┌─────────────────────────────────────────────┐    
  │  Header: magic, version, flags, hdr_len     │    
  │  Type String Table ("struct", "int", ...)   │    
  │  Type Entries[] (类型节点数组)              │    
  │                                             │    
  │  ID 0: void (BTF_VOID)                      │    
  │  ID 1: int (BTF_INT, size=4, encoding=signed)    
  │  ID 2: const int (BTF_CONST → 1)            │    
  │  ID 3: struct task_struct {                 │    
  │           volatile long state;   // off=0   │    
  │           void *stack;           // off=64  │    
  │           int pid;               // off=N   │    
  │         }                                   │    
  │  ID 4: ptr→struct task_struct (BTF_PTR → 3)│    
  │  ...                                        │    
  └─────────────────────────────────────────────┘    
                                                      
  .BTF.ext section (代码与类型的关联信息)             
  ┌─────────────────────────────────────────────┐    
  │  func_info[]: 每条指令对应的函数名           │    
  │  line_info[]: 每条指令对应的源码行号         │    
  │  field_relos[]: 关键！记录每个BPF指令中      │    
  │  对结构体成员访问的"类型指针"                │    
  │                                             │    
  │  relo[0]:                                   │    
  │    insn_offset: 偏移 40 处指令              │    
  │    type: struct task_struct                 │    
  │    member: "pid"                            │    
  │    access_size: 4                           │    
  │    access_str_off: "pid"                    │    
  │  relo[1]: ...                               │    
  └─────────────────────────────────────────────┘    
──────────────────────────────────────────────────────

2.3 BTF 类型节点分类

BTF 类型	用途	典型示例
BTF_VOID	空类型	void 类型终止节点
BTF_INT	整型（含编码）	int, unsigned long, bool（含 signedness 和 offset bit）
BTF_PTR	指针（类型引用）	struct file * → 引用 struct file 的 Type ID
BTF_ARRAY	数组	char [64] → {elem_type_id=char, nelems=64}
BTF_STRUCT	结构体	struct task_struct（含各成员 name_off + type_id + offset）
BTF_UNION	联合体	与 BTF_STRUCT 类似，所有成员 offset=0
BTF_ENUM	枚举	enum bpf_func_id → 值列表
BTF_FWD	前向声明	struct inode;（不透明，后续可能用 BTF_STRUCT 替代）
BTF_TYPEDEF	类型别名	typedef unsigned long u64
BTF_VOLATILE / CONST / RESTRICT	修饰符（链式引用）	const struct task_struct * → CONST → PTR → STRUCT
BTF_FUNC_PROTO	函数原型	用于描述 BPF 辅助函数或 BPF-to-BPF 函数签名
BTF_FUNC	函数定义	BPF 程序自身的类型
BTF_VAR	全局变量	bpf_map 和全局变量声明
BTF_DATASEC	数据段	ELF 中 .bss/.data/.rodata 的类型信息

2.4 内核 BTF 的暴露方式

内核将自身的 BTF 数据通过 sysfs 暴露给用户态：

# 原始 BTF 数据（约 4-5MB）
/sys/kernel/btf/vmlinux

# 查看 BTF 大小
$ ls -lh /sys/kernel/btf/vmlinux
-rw-r--r-- 1 root root 4.2M Jan 1 00:00 /sys/kernel/btf/vmlinux

# 提取特定类型的 BTF 信息
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c | head -20
struct task_struct {
    volatile long int               state;
    void *                           stack;
    ...
};

加载 BPF 程序时，内核验证器会将 BPF 对象文件中的 BTF 信息与 /sys/kernel/btf/vmlinux 中的类型信息建立映射，在验证过程中完成类型重定位。

3. CO-RE（Compile Once – Run Everywhere）机制详解

3.1 CO-RE 的三层技术栈

CO-RE 方案由三个核心组件构成：

──────────────────────────────────────────────────────────────
  Layer 1: 编译器支持 (Clang)                                  
  - 生成 BPF CO-RE 重定位记录                                  
  - 使用 __builtin_preserve_access_index() 捕获访问路径        
  - 从 BTF 中获取当前编译环境的类型布局                        
──────────────────────────────────────────────────────────────
  Layer 2: 库支持 (libbpf)                                     
  - 读取 .BTF 和 .BTF.ext                                     
  - 解析目标内核的 vmlinux BTF                                
  - 在加载前重写 BPF 指令中的立即数为正确偏移                  
──────────────────────────────────────────────────────────────
  Layer 3: 内核 BPF 加载器                                     
  - 接收已重写指令的 BPF 字节码                                
  - 根据 BTF 信息进行最终的类型检查和验证                      
  - 保留 BTF 引用用于调试                                      
──────────────────────────────────────────────────────────────

3.2 CO-RE 重定位的本质

让我通过一个具体例子理解 CO-RE 做了什么。假设我们要编写一个 BPF 程序，读取当前进程的 PID：

// 传统方式（硬编码偏移，不可移植）
SEC("tracepoint/syscalls/sys_enter_getpid")
int trace_getpid(struct trace_event_raw_sys_enter *ctx) {
    struct task_struct *task = (struct task_struct *)bpf_get_current_task();
    // 编译时确定：task->pid 偏移 = 2680（某内核特定版本）
    int pid = 0;
    bpf_probe_read(&pid, sizeof(int), (void *)task + 2680);
    bpf_printk("pid = %d", pid);
    return 0;
}

当目标内核的 task_struct 布局变化（例如在某个字段前插入了新字段），偏移 2680 就指向了错误的成员。

CO-RE 方式：

// CO-RE 方式（可移植）
#include "vmlinux.h"           // CO-RE 环境自动提供
#include "bpf_helpers.h"
#include "bpf_core_read.h"     // BPF CO-RE 读取辅助宏

SEC("tracepoint/syscalls/sys_enter_getpid")
int trace_getpid(struct trace_event_raw_sys_enter *ctx) {
    struct task_struct *task = bpf_get_current_task_btf();
    // BPF_CORE_READ 在加载时根据目标内核的 BTF 重定位
    int pid = BPF_CORE_READ(task, pid);
    bpf_printk("pid = %d", pid);
    return 0;
}

3.3 重定位过程详解

libbpf 在加载 BPF 对象时，执行以下重定位流程：

1. 读取 BPF .o 文件中的 .BTF 和 .BTF.ext 节区
2. 解析 .BTF.ext 中的 field relocations 记录
   每个 relo 告诉你：
   "第 X 条指令尝试访问 struct Y 的成员 Z"
   
3. 读取目标内核的 /sys/kernel/btf/vmlinux
4. 在 vmlinux BTF 中查找 struct Y 类型的定义
   对比 BPF 程序中对 struct Y 的类型描述：
   - 如果完全匹配 → 直接使用目标内核的偏移量
   - 如果成员不存在 → 报错（需要条件编译/兼容层）
   - 如果成员位置变了 → 更新为该指令中的立即数
   
5. 重写 BPF 指令
   // 原始（编译时）: *(task + 2680) → 立即数 = 2680
   // 重写（加载时）: *(task + 2992) → 立即数 = 2992 (目标内核的实际偏移)
   
6. 提交重写后的字节码给内核
7. 内核验证器执行最终的类型一致性验证

3.4 BPF_CORE_READ 家族的实现

BPF CO-RE 宏展开后使用了一个关键的内建函数：

// __builtin_preserve_access_index() 核心原理
// 这个 __builtin_ 内建函数告诉 Clang：
// "我在访问 struct X 的成员 Y，请为这次访问生成重定位记录"
// 尽管生成的 BPF 指令仍然加载该成员值，
// 但 .BTF.ext 中会增加一条记录告诉 libbpf：
// "insn #N 访问了 X.Y，需要在加载时重定位"

// BPF_CORE_READ_INTO 展开示意
#define BPF_CORE_READ_INTO(dst, src, a)     bpf_probe_read_kernel(         (dst),         __builtin_preserve_access_index(src.a),         ...)

// 生成的 BPF 指令中，偏移量是临时的（基于编译时的布局）
// libbpf 会在加载时将其替换为目标内核的正确偏移

4. vmlinux.h：一次生成，随处使用

4.1 vmlinux.h 的生成与使用

vmlinux.h 包含了当前系统内核中所有类型的 BTF 定义，可以通过 bpftool 生成：

# 从 vmlinux BTF 生成完整头文件
bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

# 该文件通常包含 150000+ 行类型定义
# 包括所有 struct、union、enum、typedef

$ wc -l vmlinux.h
237841 vmlinux.h

# 在 BPF 程序中包含它
#include "vmlinux.h"
// 此后可直接使用 struct task_struct, struct file, struct inode 等
// 无需 any kernel header！

4.2 vmlinux.h 的好处与权衡

好处：消除了对 kernel-headers 包的依赖，所有类型信息与当前部署内核完全一致。
权衡：文件体积大（编译时间稍增），但这是编译期开销，不影响运行时。
最佳实践：大部分项目将生成的 vmlinux.h 作为项目静态文件提交，不再在构建时动态生成。

4.3 进阶：选择性裁剪 vmlinux.h

对于需要最小化可执行体积的场景，可以使用 bpftool 的过滤能力：

# 仅导出特定类型的前向声明和依赖
bpftool btf dump file /sys/kernel/btf/vmlinux format c     | awk '/^struct task_struct/,/^};/' > my_vmlinux.h

5. CO-RE 高级技巧与兼容性处理

5.1 字段重命名与内核版本兼容

内核演化过程中，部分字段会发生重命名或移除（例如 task_struct.comm 在不同版本中从 char comm[16] 变为 char comm[TASK_COMM_LEN]）。CO-RE 提供多种兼容手段：

// 方法1：优化宏（避免编译器"千次重定位"爆炸问题）
// BPF_CORE_READ() 宏每次都生成重定位记录，
// 复杂访问链可能导致 .BTF.ext 过大
// 使用 BPF_CORE_READ_INTO() 替代
int pid;
BPF_CORE_READ_INTO(&pid, task, tgid);  // 重定位在初始化区，缓存结果

// 方法2：运行时条件字段选择
// 使用 bpf_core_field_exists() 探测字段是否存在
int val;
if (bpf_core_field_exists(task->prio)) {
    val = BPF_CORE_READ(task, prio);
} else {
    val = BPF_CORE_READ(task, static_pri);
}

// 方法3：可选字段重定位
// bpf_core_read() 函数 + __builtin_preserve_access_index
struct task_struct *task = ...;
int *prio_p = __builtin_preserve_access_index(&task->prio);
if (prio_p) {
    int prio;
    bpf_probe_read_kernel(&prio, sizeof(int), prio_p);
}

5.2 重定位容错与降级

CO-RE 提供了多级降级策略：

// 策略1：类型精确匹配（编译时类型 → BTF 类型）
// 如果编译器定义的类型与内核 BTF 类型 100% 匹配，直接重定位

// 策略2：类型相容匹配
// 整数类型大小不同但语义相容（如 long 在 32-bit 和 64-bit 系统）

// 策略3：字段存在性探测 + 条件执行
// bpf_core_field_exists(struct, field) 
//   返回 true/false，可在 BPF 程序逻辑中分支

// 策略4：致命失败
// 必要字段不存在 → libbpf 拒绝加载，避免静默读取错误数据

5.3 处理跨内核大版本变化

对于需要支持 Linux 4.14 → 6.x 如此大范围兼容性的工具（如商业可观测产品），CO-RE 配合 vmlinux.h 的精选版本发挥了核心作用：

// 选取"目标最低版本内核"的 BTF 生成 base vmlinux.h
// 新增字段在较新内核上才访问
// 移除字段提前编译到 BPF 程序中的兼容代码

// 示例：struct file 在 5.10 新增了 f_iocb_flags 字段
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,10,0)
    // 5.10 以下版本的替代逻辑
    int flags = BPF_CORE_READ(file, f_flags);
#else
    // 5.10+ 使用新字段
    int flags = BPF_CORE_READ(file, f_iocb_flags);
#endif

// 注意：LINUX_VERSION_CODE 在 BPF 编译环境中实际不可用
// 需要用 vmlinux.h 中的条件重定位来替代

5.4 隐形陷阱：编译器优化破坏重定位

这是实践中最常见的问题。当 BPF 程序通过多层指针间接访问结构体时，如果 Clang 在优化级别 -O2 下消去了中间步骤，重定位记录会被破坏：

// 正确：保留每一层中间记录
struct task_struct *task = ...;
int prio = BPF_CORE_READ(task, prio);  // 一条宏指令
// .BTF.ext 正确记录：insn #X → task_struct.prio

// 危险：手动拆解可能破坏优化
struct task_struct *task = ...;
int *prio_ptr = &task->prio;  // 如果Clang内联展开并优化掉，重定位丢失
int prio = *prio_ptr;

// 最佳实践：始终使用 BPF_CORE_READ 宏家族，
// 让 __builtin_preserve_access_index在正确的粒度上标记

6. CO-RE 与 BCC 的对比迁移

维度	BCC (传统)	CO-RE (现代)
编译方式	运行时 JIT 编译（需要目标机器 LLVM）	预编译 CO-RE 字节码，加载时重定位
依赖	kernel-headers + LLVM 运行时（~1GB+）	libbpf + vmlinux.h（~50KB）
启动速度	慢（数秒级 JIT）	快（毫秒级加载）
镜像大小	500MB+（含 LLVM/Clang）	5-20MB（含静态编译 libbpf）
可移植性	需同内核版本	跨内核版本（需 BTF 内核支持）
代码风格	C++ 内嵌 Python	纯 C（CO-RE），Go/Rust（通过库）
调试体验	Python 交互控制台友好	bpftool prog 命令，较工程化
学习曲线	简单（Python/C 混合）	稍需理解重定位机制

6.1 BCC 迁移到 CO-RE 示例

BCC 版本运行时编译示例：使用 Python 包裹 C 代码，运行时通过 LLVM JIT 编译 BPF 字节码。这种方式虽然简洁，但需要在每台目标机器上部署完整的 LLVM 工具链。

CO-RE 版本使用纯 C 编写 BPF 程序，通过 libbpf 在加载时利用 BTF 信息完成结构体重偏移，实现真正的"一次编译、任意内核版本部署"。

7. 大规模生产级 CO-RE 实践

7.1 Cilium：CO-RE 的工业化典范

Cilium 是完全基于 CO-RE + 自研 eBPF 库（cilium/ebpf for Go）构建的 Kubernetes CNI。其架构要求：

支持从 Linux 4.19 到最新稳定版的 BPF CO-RE 加载
无外部工具链依赖（Go 静态编译）
通过功能探测（feature probes）而非版本号来判断内核能力

Go 代码中通过 //go:generate 指令生成 BPF CO-RE C 代码，打包进最终二进制文件。

7.2 Tetragon：安全可观测的 CO-RE 实现

Cilium Tetragon 使用 CO-RE BPF 程序实施系统级安全策略和追踪。其关键设计：

单一 BPF CO-RE 对象文件内置多个探针程序
通过 CO-RE 获取进程的 UID/GID/namespace 等上下文信息（内核结构体都可能在版本间不同）
用户态通过 ring buffer 接收内核事件，不依赖 perf_event 的兼容性

7.3 Parca/BurnCHF：CO-RE 性能采样

Parca 是一个基于 eBPF 的持续性能分析器，使用 CO-RE 采集栈帧和进程上下文：

CO-RE 确保跨内核版本的 unwind table 解析
BTF 记录所有函数类型的参数签名
无需 Frame Pointer 也能通过 .eh_frame + BTF 数据重建栈帧

7.4 生产部署 Checklist

□ 确认目标内核启用 CONFIG_DEBUG_INFO_BTF=y
  （可通过 cat /sys/kernel/btf/vmlinux 验证）

□ 生成或获取匹配的 vmlinux.h

□ 使用 +btf 标志编译 BPF 程序
  clang -O2 -g -target bpf -c prog.bpf.c -o prog.bpf.o

□ 确认 .BTF 和 .BTF.ext 节区存在
  llvm-objdump -h prog.bpf.o | grep BTF
  → 应看到 .BTF 和 .BTF.ext 两行

□ 在最低目标内核版本上测试加载
  bpftool prog load prog.bpf.o /sys/fs/bpf/test

□ 验证重定位成功
  bpftool prog show pinned /sys/fs/bpf/test

□ 集成到 CI/CD 中进行跨内核版本测试
  建议使用 vmtest 或类似框架在多个内核版本上验证

8. BTF 的未来演进

8.1 Kernel BTF 的进一步扩展

Linux 6.x 内核中 BTF 持续扩展：

模块级 BTF：不仅 vmlinux，内核模块也可以携带自己的 BTF 数据（/sys/kernel/btf/<module>）。
BPF trampoline 增强：BTF func 信息使得 fentry/fexit BPF 程序与被追踪函数参数精确对接。
BTF 与 kfunc：内核导出函数时带 BTF 签名，BPF 程序可直接调用。

8.2 用户态 BTF

CO-RE 的理念正从内核 BPF 扩展到用户态程序：

用户态进程的 BTF：通过 -g 编译生成，可用于用户态 BPF 调试（uprofile）。
内核追踪用户态：BPF 程序利用用户态 BTF 信息解析追踪进程中的数据布局（如 Java 对象结构通过特定工具提供）。

8.3 Rust 与 CO-RE

Rust BPF 框架（libbpf-rs、Aya）已将 CO-RE 作为一等公民支持：

Aya：纯 Rust BPF 框架，支持 CO-RE，利用 Rust 的类型系统在编译期辅助重定位。
安全抽象：Rust 的借用检查器避免了 BPF 程序中常见的手动 bpf_probe_read 内存安全问题。
未来：随着 Rust 进入 Linux 内核，vmlinux.h 的 Rust 版（vmlinux.rs）可能成为标准。

9. 总结：CO-RE 改变了BPF的规则

CO-RE 的出现标志着 BPF 从"实验性工具"走向"生产级基础设施"的关键转折。它解决了困扰社区多年的可移植性瓶颈，使得 BPF 程序的部署模式从"每个目标编译"变为"编译一次，到处运行"——这恰是 Java/JVM 20 年前对行业做的贡献。BTF 提供的自描述元数据使 BPF 工具链实现了真正的解耦：内核开发者不需要关心 BPF 程序的兼容性，BPF 开发者也不需要打包庞大的内核头文件。今天，从 Cilium 的 Kubernetes 网络到 Tetragon 的内核安全，从 Parca 的持续性能分析到 Pixie 的即时可观测性，CO-RE 已经成为现代可编程内核基础设施的基石。未来随着 BTF 在用户态和跨领域的扩展，CO-RE 的影响力将持续突破 BPF 生态的边界。

点赞(0) 打赏

本文分类：编程技术
本文标签：BTF CO-RE BPF eBPF libbpf VMLinux Portability Linux Kernel Programming Observability Performance
浏览次数：1 次浏览
发布日期：2026-09-30 03:15:25
本文链接：https://www.ybb.press/programming/10070.html

上一篇 > Linux内核 io_uring 深度实战：高性能异步IO的架构原理与生产实践
下一篇 > Test

Linux内核BTF与CO-RE深度实战：可移植BPF程序的架构原理与生产实践

引言

1. BPF可移植性问题的由来

1.1 传统BPF编译模式的困境

1.2 曾经的解决方案及其局限

2. BTF（BPF Type Format）：类型的自描述元数据

2.1 BTF 的诞生背景与设计目标

2.2 BTF 数据格式详解

2.3 BTF 类型节点分类

2.4 内核 BTF 的暴露方式

3. CO-RE（Compile Once – Run Everywhere）机制详解

3.1 CO-RE 的三层技术栈

3.2 CO-RE 重定位的本质

3.3 重定位过程详解

3.4 BPF_CORE_READ 家族的实现

4. vmlinux.h：一次生成，随处使用

4.1 vmlinux.h 的生成与使用

4.2 vmlinux.h 的好处与权衡

4.3 进阶：选择性裁剪 vmlinux.h

5. CO-RE 高级技巧与兼容性处理

5.1 字段重命名与内核版本兼容

5.2 重定位容错与降级

5.3 处理跨内核大版本变化

5.4 隐形陷阱：编译器优化破坏重定位

6. CO-RE 与 BCC 的对比迁移

6.1 BCC 迁移到 CO-RE 示例

7. 大规模生产级 CO-RE 实践

7.1 Cilium：CO-RE 的工业化典范

7.2 Tetragon：安全可观测的 CO-RE 实现

7.3 Parca/BurnCHF：CO-RE 性能采样

7.4 生产部署 Checklist

8. BTF 的未来演进

8.1 Kernel BTF 的进一步扩展

8.2 用户态 BTF

8.3 Rust 与 CO-RE

9. 总结：CO-RE 改变了BPF的规则

评论列表共有 0 条评论

发表评论取消回复

Linux内核BTF与CO-RE深度实战：可移植BPF程序的架构原理与生产实践

引言

1. BPF可移植性问题的由来

1.1 传统BPF编译模式的困境

1.2 曾经的解决方案及其局限

2. BTF（BPF Type Format）：类型的自描述元数据

2.1 BTF 的诞生背景与设计目标

2.2 BTF 数据格式详解

2.3 BTF 类型节点分类

2.4 内核 BTF 的暴露方式

3. CO-RE（Compile Once – Run Everywhere）机制详解

3.1 CO-RE 的三层技术栈

3.2 CO-RE 重定位的本质

3.3 重定位过程详解

3.4 BPF_CORE_READ 家族的实现

4. vmlinux.h：一次生成，随处使用

4.1 vmlinux.h 的生成与使用

4.2 vmlinux.h 的好处与权衡

4.3 进阶：选择性裁剪 vmlinux.h

5. CO-RE 高级技巧与兼容性处理

5.1 字段重命名与内核版本兼容

5.2 重定位容错与降级

5.3 处理跨内核大版本变化

5.4 隐形陷阱：编译器优化破坏重定位

6. CO-RE 与 BCC 的对比迁移

6.1 BCC 迁移到 CO-RE 示例

7. 大规模生产级 CO-RE 实践

7.1 Cilium：CO-RE 的工业化典范

7.2 Tetragon：安全可观测的 CO-RE 实现

7.3 Parca/BurnCHF：CO-RE 性能采样

7.4 生产部署 Checklist

8. BTF 的未来演进

8.1 Kernel BTF 的进一步扩展

8.2 用户态 BTF

8.3 Rust 与 CO-RE

9. 总结：CO-RE 改变了BPF的规则

Linux内核网络栈深度实战：从数据包收收到协议栈处理全链路解析

Linux内核NUMA内存管理架构深度实战：从UMA/NUMA拓扑到自动均衡与性能优化全解

eBPF Map 生产级工程实战：从 PerCPU Hash 到 Queue/Stack 的深度优化

Linux内核Lockdep深度实战：从死锁检测到依赖图验证的静态分析全解

评论列表 共有 0 条评论

发表评论 取消回复

评论列表共有 0 条评论

发表评论取消回复