On Fri, Sep 25, 2020 at 4:58 PM Yaniv Agman <yanivagman@xxxxxxxxx> wrote: > > Hello, > > I'm developing a tool which is now based on BCC, and would like to > make the move to libbpf. > I need the tool to support a minimal kernel version 4.14, which > doesn't have CO-RE. You don't need kernel itself to support CO-RE, you just need that kernel to have BTF in it. If the kernel is too old to have CONFIG_DEBUG_INFO_BTF config, you can still add BTF by running `pahole -J <path-to-vmlinux-image>`, if that's at all an option for your setup. > > I have read bcc-to-libbpf-howto-guide, and looked at the libbpf-tools of bcc, > but both only deal with newer kernels, and I failed to change them to > run with a 4.14 kernel. > > Although some of the bpf samples in the kernel source don't use CO-RE, > they all use bpf_load.h, > and have dependencies on the tools dir, which I would like to avoid. Depending on what exactly you are trying to achieve with your BPF application, you might not need BPF CO-RE, and using libbpf without CO-RE would be enough for your needs. This would be the case if you don't need to access any of the kernel data structures (e.g., all sort of networking BPF apps: TC programs, cgroup sock progs, XDP). But if you need to do anything tracing related (e.g., looking at kernel's task_struct or any other internal structure), then you have no choice and you either have to do on-the-target-host runtime compilation (BCC way) or relocations (libbpf + BPF CO-RE). This is because of changing memory layout of kernel structures. So, unless you can compile one specific version of your BPF code for a one specific version of the kernel, you need either BCC or BPF CO-RE. > > I would appreciate it if someone can help with a simple working > example of using libbpf on 4.14 kernel, without having any > dependencies. Specifically, I'm looking for an example makefile, and > to know how to load my bpf code with libbpf. libbpf-tools's Makefile would still work. Just drop dependency on vmlinux.h and include system headers directly, if necessary (and if you considered implications of kernel memory layout changes). > > Thanks, > Yaniv
