ebpf相关知识的链接

夏天

https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md  ebpf对应的 内核版本特性 能解决什么问题 *

https://lore.kernel.org/bpf/ ebpf对应的内核ebpf补丁的信息讨论 *

https://juejin.cn/post/6844903657754853383 Linux未来监控tracing框架——eBPF 各种tracing框架的对比 分为前端，tracing框架，探针 *

夏天

ebpf和内核模块都对应着内核探针的数据源，并不是ebpf自己的东西

夏天

linux参考资料 :鸟哥的linux 作者台湾人

超链接登录可见。

夏天

https://www.cnblogs.com/revercc/p/17803876.html
eBPF 的 uprobe 程序与内核 kernel/events/uprobe.c 的联系，本质上是 eBPF 机制复用了内核原生的 uprobe 基础设施 来实现用户态函数的钩子功能。具体来说，eBPF 的 uprobe 是内核 uprobe 框架的一种 “应用”，两者通过内核内部的调用链和数据结构关联起来。
核心联系：eBPF 依赖内核 uprobe 框架实现钩子
内核 uprobe.c 是 Linux 内核原生用户态探针（uprobe）的核心实现，负责：
管理用户态探针的注册、注销（如 register_uprobe()、unregister_uprobe()）。
处理断点插入（向目标函数地址写入断点指令，如 x86 的 int3）。
捕获断点触发事件（当程序执行到断点时，陷入内核态处理）。
调用预注册的回调函数（即钩子逻辑）。
而 eBPF 的 uprobe 程序（如你写的 hook libc.so 的例子），本质是通过 eBPF 加载器（如 bcc、libbpf）向内核 注册了一个基于 uprobe 的 eBPF 回调函数，这个过程完全依赖 uprobe.c 提供的基础设施。
具体调用链：从 eBPF 程序到 uprobe.c 的流程
当你通过 eBPF 加载器（如 bcc 的 attach_uprobe）注册一个 uprobe 时，底层流程如下：
eBPF 加载器发起注册请求加载器（如 bcc 的 Python 代码）通过系统调用（如 bpf() 或 perf_event_open()）告知内核：“我要在 libc.so 的 openat 函数上挂一个 eBPF 钩子”，并传递 eBPF 程序的字节码。
内核验证并准备 eBPF 程序内核 eBPF 验证器检查程序合法性，确保其不破坏内核安全。通过后，将 eBPF 程序加载到内核，并准备好一个 “eBPF 回调函数”（即你写的 uprobe_openat 逻辑）。
复用 uprobe.c 的注册接口内核内部会调用 uprobe.c 中的 register_uprobe() 函数，注册一个 “原生 uprobe”，并将 eBPF 回调函数作为这个 uprobe 的 “触发处理函数”。
这里的关键是：eBPF 的 uprobe 本质是 给内核原生 uprobe 绑定了一个 eBPF 类型的回调。
uprobe.c 插入断点并等待触发uprobe.c 会根据注册的目标地址（libc.so 中 openat 的地址），向用户态内存写入断点指令（如 x86 的 int3），并记录断点的原始指令（用于触发后恢复执行）。
函数调用触发断点，uprobe.c 调用 eBPF 回调当应用程序调用 libc.so:openat 时，执行到断点指令会触发陷阱（trap），陷入内核态。此时：
内核会调用 uprobe.c 中的 uprobe_handler() 函数（核心处理逻辑）。
uprobe_handler() 会检查该断点对应的注册信息，发现绑定了 eBPF 回调，于是调用 eBPF 程序（即你写的 uprobe_openat）。
eBPF 程序执行（如收集参数、写入 ringbuf）后，uprobe_handler() 恢复原始指令，让程序继续执行。
总结：两者的关系
kernel/events/uprobe.c 是 底层基础设施，提供了用户态断点的插入、捕获、恢复等核心能力，是所有用户态探针（包括 eBPF uprobe、gdb 调试等）的基础。
eBPF 的 uprobe 程序是 基于这套基础设施的上层应用，通过注册 eBPF 回调函数，让内核在 uprobe 触发时执行 eBPF 逻辑，从而实现高效的用户态函数跟踪。
简单说：eBPF 的 uprobe 是 “用户”，uprobe.c 是 “服务提供者”，前者依赖后者完成钩子的注册、触发和执行。