hugo/content/posts/bpfminimal2.md
2022-03-24 09:34:09 +08:00

2.3 KiB
Raw Permalink Blame History

+++ title = "bpf minimal c 分析" author = "Logic" date = 2022-03-08 draft = false +++

minimal C 源码分析

libbpf_set_strict_mode

这个函数的作用乍一看让人摸不着头脑查看Andrii Nakryiko的博客Building BPF applications with libbpf-bootstrap可发现在该篇博文中出现的用于解除用户内存限制的 bump_memlock_rlimit() 函数并没有出现最新的minimal.c文件中新增的函数即 libbpf_set_strict_mode() 可推测该函数起到了之前bump函数的作用。但对于该API的说明在源码中并没有给出相关的注释查看libbpf github上release记录查找有关的变化说明最终可以找到Libbpf 1.0 migration guide,其中对该API给出了说明。可见该API的的作用在于启动libbpf 1.0的新特性在最新的release v0.7中说明了有关特性,即

no need for explicit setrlimi(RLIMIT_MEMLOCK) when LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK is passed to libbpf_set_strict_mode(). libbpf will determine whether this is necessary automatically based on kernel's support for memcg-based memory accounting for BPF;

libbpf会自动根据需求和内核支持来进行相应的内存变化,这一特性实在是太新了,所以搜索不到任何说明,只能跟踪源码仓库变化了解。

其余部分

其余部分的解析在Andrii的博客中有非常详细的说明,在此不再赘述这里主要再讨论一下这几个文件之间的关系minimal.bpf.c其实是bpf程序的主体文件在其中定义的全局变量即是bpf程序中的map表用于bpf程序内的数据交互和监控。该变量在通过bpftool生成skel文件时会被放入minimal_bpf这一结构体的bss结构中相当于放入elf文件的数据段中这样minimal.c文件就可以通过读取该结构中的数据来将一些数据从用户空间传入内核bpf结构中。minimal.c则是用户想要进行的一些处理比如打印某些信息或将信息进一步传递。