Most examples of BPF code are written in a mix of Python and C using BCC, the "BPF Compiler Collection", which essentially treats all of LLVM and clang as a library callable from Python code.<p>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).<p>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:<p><a href="https://facebookmicrosites.github.io/bpf/blog/2020/02/20/bcc-to-libbpf-howto-guide.html" rel="nofollow">https://facebookmicrosites.github.io/bpf/blog/2020/02/20/bcc...</a>
Spectre mitigations can make it go from awesome to useful.<p>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)
It seems worth mentioning that the code actually executing in the kernel, when it is running your eBPF, is native machine code, ahead-of-time compiled from the bytecode program you gave to the kernel.
Yup, it is. My recent epiphany-blogpost:<p><a href="https://blog.habets.se/2020/11/BPF-the-future-of-configs.html" rel="nofollow">https://blog.habets.se/2020/11/BPF-the-future-of-configs.htm...</a>
Is it possible to write device drivers in eBPF?<p>(I've asked this before, but haven't gotten any response, and no clear answer from Google/DDG either).
What are the benefits of using eBPF besides a promise of observability "for free"?<p>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?<p>How does eBPF work wrt OpenTelemetry etc.? Should OpenTelemetry be seen as standardized interfaces to which eBPF reports data?
I just happen to run into a freebsd video on dtrace (similar technology to eBPF, I think) that was created three weeks ago.<p><a href="https://www.youtube.com/watch?v=E06GVdH-LX0" rel="nofollow">https://www.youtube.com/watch?v=E06GVdH-LX0</a>