On Wed, Oct 27, 2021 at 1:37 PM Mauricio Vásquez <mauricio@xxxxxxxxxx> wrote: > There is also a good example[3] on how to use BTFGen and BTFHub together > to generate multiple BTF files, to each existing/supported kernel, > tailored to one application. For example: a complex bpf object might > support nearly 400 kernels by having BTF files summing only 1.5 MB. Could you share more details on what kind of fields and types were used to achieve this compression? Tracing progs will be peeking into task_struct. To describe it in the reduced BTF most of the kernel types would be needed, so I'm a bit skeptical on the practicality of the algorithm. I think it may work for sk_buff, since it will pull struct sock, net_device, rb_tree and not a ton more. Have you considered generating kernel BTF with fields that are accessed by bpf prog only and replacing all other fields with padding ? I think the algo would be quite different from the actual CO-RE logic you're trying to reuse. If CO-RE matching style is necessary and it's the best approach then please add new logic to bpftool. I'm not sure such api would be useful beyond this particular case to expose as stable libbpf api. Also note that relo_core.c soon will be dual compiled for kernel and libbpf needs.
