I can't get my head around using it that way, and have found it pretty straightforward to just write C programs, compiled with clang `-target bpf`. Until very recently, writing anything interesting this way required you to declare all functions inline, compile into a single ELF .o, and, of course, avoid most loops. But most of the kinds of things you'd write in BPF tend not to be especially loopy (you can factor most algorithmic code out into userland, communicating with BPF using maps).
A big issue for this kind of development is kernel compat; struct layouts can change from release to release, for instance. This isn't a problem for us at Fly, because we just run the same kernel everywhere, but it's a real problem if you're trying to ship a tool for other people's systems. But that's changing with CO-RE; recent kernels can export a simplified symbol table in a BPF-legible format called BTF, and the leader can perform relocations. Facebook has written a bunch of good stuff about this:
https://facebookmicrosites.github.io/bpf/blog/2020/02/20/bcc...
It seems somewhat unavoidable, if the goal is to introspect the kernel at a very intimate level ...
https://github.com/weaveworks/tcptracer-bpf/blob/cd53e7c84ba...
This was done (by Kinvolk) for the visualisation tool Weave Scope; also picked up by DataDog https://github.com/DataDog/datadog-process-agent/tree/master...
I'm not sure the state of them at this point, but it's the same paradigm GP mentioned.
The documentation is also pretty dire, but it's mostly implement-once remember-forever in my experience - it's all there but kernel samples are quite hard to read, and I'd rather not guess based on struct listings (e.g. variable length structs aren't particularly fun when you're fumbling around)
JIT compilation means compiling code on the fly right when you're about to execute it. When the code is part of a larger program, jitting allows to compile the parts of it you actually need and avoid wasting time to compile other parts. It also allows to compile the relevant code paths based on dynamic flow analysis, which often involves interpreting your program the first time you run it and emitting instructions for the next time around (tracing)
If the code unit is small and you know you're going to run it all, you can compile it in one swoop. If you compile it when you load it in the kernel, as opposed to compiling it lazily right before you run it the first time, i think it's fair to call this Ahead-of-Time compilation, even if the compilation happens right next the use site and not as part of the developer tool chain
https://blog.habets.se/2020/11/BPF-the-future-of-configs.htm...
Isn't it actually running a user program in kernel space?
(I've asked this before, but haven't gotten any response, and no clear answer from Google/DDG either).
Can eBPF be used for observability using platforms like Java or .net core, or does their platform VMs obfuscate too much and monitoring them using eBPF is not feasible?
How does eBPF work wrt OpenTelemetry etc.? Should OpenTelemetry be seen as standardized interfaces to which eBPF reports data?
OpenTelemetry is just a reference API. You could export metrics using eBPF as well. I'm pretty sure Sysdig does this for example.
http://www.brendangregg.com/blog/2014-06-12/java-flame-graph...
Pseudo? This is a nit, but isn't it actually regular C?
Your toolbox can be used to fix things, but eBPF is a factory for making new types of tools and toolboxes.
eBPF can be used to make small programs that run at tracing points, thus making dtrace. But it can also be made to make packet filter decisions (thus altering what happens), and with at least one network card that eBPF program can be pushed to the network card and filter before the packet even hits RAM, much less the CPU!
eBPF can run at socket init time, and set some default TCP tuning parameters.
Another comment in this thread asked if one can write a whole device driver in eBPF. The answer is actually not clear.
eBPF is more similar to "the ability to load kernel modules" than it is "a tracing framework".
Sadly, I don't program in Linux, so I can't use it. :'(
[0]https://github.com/microsoft/perfview/blob/master/documentat...
My general development skill (in Linux or otherwise) has definitely improved since I became a Linux native. But that didn't happen overnight.
