Usenix LISA2021 BPF Internals (eBPF)

brendangregg.com

52 points·r4um··5 comments

Great end-to-end overview!

It's interesting to see people stick to bpftrace for the high-level language and bcc for the low-level one. If there is a bytecode VM, I expect many languages to bloom, especially the VM is embedded into the most popular open source software - Linux.

I don't say bpftrace or C is bad, but they are rather classic. In typical OSS community, PL enthusiasts chime in, nitpick and eventually build something fancier (which is good sometimes and bad other times). Isn't it happening here in BPF? Is the domain too niche, or is the VM capability too limited?

There is a fair bit of co-evolution of the Linux BPF verifier and the BPF llvm backend. This means that the verifier is biased to do well on bytecode that is commonly emitted by clang. I can imagine that other programming languages will run into the verifier rejecting their output if it differs to much from common clang output. (There is redbpf which compiles rust to BPF AFAIK, but it still uses llvm. There is also a gcc BPF backend, but I don't have experience with that.) The good news is that Linux upstream is receptive to bug reports!

So it's more coupled than it appears. That makes sense. Thanks for the tip!

bpftrace is considering adding a new backend that wouldn't involve any LLVM[0].

Additionally, ply is another effort (which doesn't use LLVM) to build a DTrace-like frontend to BPF.[1]

[0] https://github.com/iovisor/bpftrace/issues/1845

[1] https://github.com/iovisor/ply

The bcc toolkit has been out for a while [1], it is a great collection of python wrapped bpf tools that is a little more user friendly.

[1] https://github.com/iovisor/bcc

Reply on news.ycombinator.com