Thoughts on eBPF (now called BPF?)

Recently, there has been a lot of hype around BPF, and some of the engineers I follow quite closely like Brendan Gregg are heavily invested in it. For those of you who don’t know, BPF can be simply described as an in-kernel VM that can be used for low-overhead tracing and obervability (like dtrace is on MacOS and Solaris) and it is in fact already used by everyday tools like tcpdump and in the enterprise by Netflix, Facebook and other.

However, after I watched this talk by Brendan Gregg, it is starting to bother me more and more. People are talking about writing full applications on top of BPF, using it to basically do anything and everything. It sounds scarily close to the new systemd.

I am not a kernel person myself and understand very little about topics like this, but shouldn’t we define the scope of a technology and then implement it, and not the other way round? The direction BPF is headed in looks more like the trajectory of Java than that of, say, Rust or C.

If anyone wants to correct me, or pitch their own thoughts about BPF let me know. I am curious, and I don’t think I have the complete picture just yet.

1 Like