009.BTF的历史

下面把时间线和概念一次说清楚。

---

一、BTF 是什么时候引入内核的？

BTF（BPF Type Format）最早进入 Linux 内核是在 5.2 左右，而不是 5.4。

更准确的说法是：

🧩 BTF 的三个阶段

① 5.2：BTF 基础设施进入内核

• 内核开始支持 BTF 数据结构
• 可以在内核中携带类型信息
• 这是 BTF 的“诞生”

但此时：

• 能干的事情不多
• 还没有 eBPF CO-RE
• 工具链也不成熟

---

② 5.4：BTF 开始“可用”

5.4 是一个关键节点，很多人会误以为是“BTF 起点”，原因在这里：

• vmlinux BTF 开始被大规模启用
• 发行版（Ubuntu / Fedora）开始默认开启：

CONFIG_DEBUG_INFO_BTF=y

• BPF 程序可以稳定读取内核类型信息
• 为后续 CO-RE 铺平道路

👉 所以：

5.4 是“BTF 开始进入工程实践”的版本

---

③ 5.6 ~ 5.8：CO-RE 成熟

• 引入并完善：
  • bpf_core_read()
  • __builtin_preserve_access_index
• libbpf 开始真正支持 一次编译，多内核运行

从这个阶段开始：

BTF + CO-RE 成为 eBPF 的核心竞争力

---

二、那 5.10 为什么被认为“稳定”？

你说 5.10 是稳定版本，这个说法 在工程语境下是对的，但要精确定义。

1️⃣ 5.10 是 LTS（长期支持内核）

• Linux 官方指定：
  • 5.10 = LTS
  • 生命周期非常长（多年安全补丁）
• 大量云厂商、发行版选择它作为基线：
  • Android
  • Debian
  • 各类云内核

👉 这是“稳定”的第一个含义：长期维护

---

2️⃣ 对 eBPF 来说，5.10 是“工业级稳定点”

对你现在做的这些事情（eBPF / tracing / CO-RE）来说，5.10 非常关键：

• BTF 几乎 100% 可用
• CO-RE 成熟
• libbpf API 稳定
• kprobe / tracepoint / perf / ringbuf 都进入“可放心使用”阶段
• 各大 eBPF 项目（bcc → libbpf）全面转向

很多项目的真实底线是：

< 5.4   ❌ 太原始
5.4~5.8 ⚠️ 勉强
>= 5.10 ✅ 工程级推荐

---

三、为什么你会“感觉 BTF 是 5.4 引入的”？

这是一个非常合理的错觉，原因有三点：

1. 发行版默认开启 BTF 从 5.4 开始
2. 教程/博客大量写：

“5.4+ 支持 BTF”

3. 真正写 eBPF 的人，在 5.2 / 5.3 几乎没人用 BTF

👉 所以大家在“体感上”会把 5.4 当成起点

---

四、一句话总结（给课程 / 文章用）

你可以这样表述，既严谨又工程化：

• BTF 在 Linux 5.2 引入内核
• 从 5.4 开始随发行版广泛启用
• 在 5.10 之后，BTF + CO-RE 成为稳定可依赖的工程能力

或者更“工程师口径”一点：

eBPF 真正进入可规模化工程应用，是从 Linux 5.10 开始的。