【eBPF 内核实现深度拆解】从验证器到 JIT，从 BTF 到调度器
内容提要
该文介绍eBPF内核实现深度拆解系列，涵盖BPF指令集、验证器、JIT编译、Map、BTF与CO-RE、sched_ext等核心机制，共21篇，面向内核及平台工程师，提供源码级解析与推荐阅读路径，旨在填补中文技术资料空白。
延伸解读
为什么需要这份资料
中文互联网上关于 eBPF 的教程大多停留在应用层面，比如用 bpftrace 排查问题，但缺少对内核实现的系统性剖析。本文档正是为了填补这一空白，从 BPF 指令集、验证器、JIT 到 BTF 和 sched_ext，逐层拆解 eBPF 成为“内核第二用户态”的机制基础。对于想深入理解 eBPF 工作原理的开发者来说，这是一份难得的源码级参考资料。
阅读路径建议
文档提供了多条推荐阅读路径，针对不同读者群体：内核开发者可关注验证器与安全模型，基础设施工程师可聚焦 Map 与 libbpf，平台工程师可深入 CO-RE 与编译工具链，而对前沿感兴趣者可探索 sched_ext 与非 Linux 实现。建议根据自身角色选择路径，避免盲目通读，提高学习效率。
源码版本与可复现性
文档强调以 Linux 6.6/6.8 LTS 源码为主线，并标注关键函数路径和行号，同时提供可编译的示例代码（如第 20 篇的微型 Agent）。这种“源码驱动”和“可复现验证”的策略，有助于读者在实践中验证理论，但需注意不同内核版本间的差异，阅读时需留意版本标注。
Q&A
eBPF 内核实现深度拆解系列主要面向哪些读者？
该系列主要面向 Linux 内核工程师、基础设施平台工程师、高性能网络/安全工程师以及 eBPF 工具链开发者，也适合对内核机制有深入兴趣的后端/SRE 工程师。
eBPF 从 cBPF 演变而来，最初在哪个 Linux 版本中合入？
2014 年 Alexei Starovoitov 将 cBPF 重写为 eBPF 并合入 Linux 3.18。
eBPF 验证器（verifier）如何保证内核安全？
验证器通过抽象解释（abstract interpretation）跟踪每个寄存器的类型和值域，使用状态裁剪（state pruning）控制搜索空间，并通过等价状态合并（precision tracking）避免路径爆炸，从而静态分析 BPF 程序，确保其安全执行。
BPF JIT 编译器相比解释器能快多少？
文章指出具体倍率取决于程序形态，需要在本机 benchmark 验证，没有给出固定数值。
BPF Map 类型选择不当会有什么影响？
选错 map 类型在典型高并发场景下可能带来显著性能退化，具体幅度依 workload 而定。
CO-RE 机制依赖哪些关键组件？
CO-RE 依赖 BTF 格式规范、clang 的 preserve_access_index 内置函数，以及 libbpf 在加载时执行的重定位修补。
sched_ext 是什么？它如何让 BPF 参与调度？
sched_ext 是 eBPF 进入调度器的一次范式实验，它通过 struct_ops 回调接口（如 select_cpu、enqueue、dispatch 等）将调度策略变成运行时可编程，使 BPF 程序能够安全地参与调度决策。
本系列推荐的阅读路径中，内核开发者想理解 eBPF 安全机制应该按什么顺序阅读？
内核开发者想理解 eBPF 如何保证安全，推荐路径是 01 → 02 → 03 → 04 → 05 → 17。
本系列承诺提供哪些内容？
承诺包括：核心机制配内核源码路径和关键数据结构定义；verifier / JIT / CO-RE 三段核心链路给出可追踪的调用路径；Map 实现分析覆盖所有常用 BPF_MAP_TYPE_* 的 map_ops 实现差异；第 20 篇提供完整可编译可运行的 BPF Agent 示例代码。
