Using bpftool skeleton

[parttimenerd]

Maybe bpftool skeleton could be used later? Any ideas?

[captain5050]

So the way BCC works is a little bit antiquated as I understand it for BPF. BPF programs loading into the kernel are similar to how the JVM can have classloaders that load classes. In Java if an API changed the class loader would throw some kind of Exception/Error from the spec at load time. For the Linux kernel APIs changing is something of the norm, for example, the task data structure (used by processes and threads) may or may not have cgroup (container) information accessible from it. This is determined at compile time for the Linux kernel based on #ifdefs. For BPF programs this is a nuisance as they want to compile with known offsets, there was no symbolic lookup like with Java class files. To solve this BCC would compile the BPF C code at runtime and "reflect" on the Linux kernel to work out offsets and the like. Header files would be built at runtime and then used in the BPF program's C code.

Modern BPF programs are different because of CO-RE:
https://facebookmicrosites.github.io/bpf/blog/2020/02/19/bpf-portability-and-co-re.html
CO-RE adds extra debug information (like is in Java class files) so that a loaded BPF program can have its offsets adjusted for particular structs, enums renumbered, etc. Being able to do this at load time avoids the tool having to have say libclang dependencies and do runtime compilation. Distributing a Linux program with the BPF CO-RE program compiled in as a skeleton is much easier this way. This is the way, for example, the Linux perf tool now loads BPF programs to annotate system calls for "perf trace".

[parttimenerd]

I also saw this problem, but thanks for the brief explanation.

Do I understand correctly that this would entail

1. removing the BCC APIs,
2. precompiling the BPF programs in a pre-processing step during compilation into BPF bytecode,
3. and then, should we store this bytecode in the built JAR?

It sounds like quite a lot of work (especially the first part), but certainly something I want to tackle in the future.

[captain5050]

So there may be a world where people want BCC like runtime compilation functionality, but CO-RE just feels better. Both BCC and say libbpf-tools that uses CO-RE, are built on libbpf so I think abstracting libbpf is a primary problem. You could do that with a tool like SWIG, but it would be horrible and a hand abstraction would be better. It'd also be kind of cool to keep as much code in Java as possible - the syscall to bpf(...) is obviously something Java lacks. Similarly the C code that bpftool generates for a skeleton could just be Java wrapped, but it may be fun/possible to do it in Java. libbpf and skeletons allows some sharing of definitions and state, pulling that off in Java may be harder. Anyway, the point of my comment was to advise against being too close to BCC and runtime compilation as CO-RE would likely be a better approach.

[parttimenerd]

So there may be a world where people want BCC like runtime compilation functionality, but CO-RE just feels better.

And it would allow to create JARs with all dependencies included.

It'd also be kind of cool to keep as much code in Java as possible - the syscall to bpf(...) is obviously something Java lacks.

But with project panama, it's pretty easy to create a wrapper.

Similarly the C code that bpftool generates for a skeleton could just be Java wrapped, but it may be fun/possible to do it in Java. libbpf and skeletons allows some sharing of definitions and state, pulling that off in Java may be harder.

I'll have to look into this. Using the skeletons with Panama should not be the largest problem. But creating the skeleton in Java without bpftool might be easier. This an area where I probably need help.

Anyway, the point of my comment was to advise against being too close to BCC and runtime compilation as CO-RE would likely be a better approach.

I hope to leave BCC behind in the near future. The code base isn't too large currently and most new code won't be tied to BCC.