ebpf VS illumos-gate

Oh, no I don't mean that arbitrary Go compiles to eBPF. Apologies if I gave that impression. I meant that there are libraries that let you compose eBPF programs in other languages. But you're still putting together an eBPF program, just like you can assemble JSON with Go but you can't compile an arbitrary Go program to JSON.

Cilium's eBPF library is the Go one I had in mind: https://github.com/cilium/ebpf

Here's an example from that repo: https://github.com/cilium/ebpf/tree/main/examples/ringbuffer

The whole BPF verifier and development process is so botched, it's ridiculous. It's like maintainers decided to make this as hard as possible out of pettiness and "they have to use C APIs instead" or something.

- Loading an eBPF module without the CAP_BPF (and in some cases without the CAP_NET_ADMIN which you need for XDP) capabilities will generate a "unknown/invalid memory access" error which is super useless as an error message.

- In my personal opinion a bytecode format for both little endian (bpfel) and big endian (bpfeb) machines is kinda unnecessary. I mean, it's a virtual bytecode format for a reason, right!?

- Compiling eBPF via clang to the bpf bytecode format without debug symbols will make every following error message down the line utterly useless. Took me a while to figure out what "unknown scalar" really means. If you forget that "-g" flag you're totally fucked.

- Anything pointer related that eBPF verifier itself doesn't support will lead to "unknown scalar" errors which are actually out of bounds errors most of the time (e.g. have to use if pointer < size(packet) around it), which only happen in the verification process and can only be shown using the bpftool. If you miss them, good luck getting a better error message out of the kernel while loading the module.

- The bpftool maintainer is kind of unfriendly, he's telling you to read a book about the bytecode format if your code doesn't compile and you're asking about examples on how to use pointers inside a BPF codebase because it seems to enforce specific rules in terms of what kind of method (__always_static) are allowed to modify or allocate memory. There's a lot of limitations that are documented _nowhere_ on the internet, and seemingly all developers are supposed to know them by reading the bpftool codebase itself!? Who's the audience for using the bpftool then? Developers of the bpftool itself?

- The BCC tools (bpf compiler collection) are still using examples that can't compile on an up-to-date kernel. [1] If you don't have the old headers, you'll find a lot of issues that show you the specific git hash where the "bpf-helpers.h" file was still inside the kernel codebase.

- The libbpf repo contain also examples that won't compile. Especially the xdp related ones [2]

- There's also an ongoing migration of all projects (?) to xdp-tools, which seems to be redundant in terms of bpf related topics, but also has only a couple examples that somehow work [3]

- Literally the only userspace eBPF generation framework that worked outside a super outdated enterprise linux environment is the cilium ebpf project [4], but only because they're using the old "bpf-helpers.h" file that are meanwhile removed from the kernel itself. [5] They're also incomplete for things like the new "__u128" and "__bpf_helper_methods" syntax which are sometimes missing.

- The only working examples that can also be used for reference on "what's available" in terms of eBPF and kernel userspace APIs is a forked repo of the bootlin project [6] which literally taught me how to use eBPF in practice.

- All other (official?) examples show you how to make a bpf_printk call, but _none_ of them show you how to even interact with bpf maps (whose syntax changed like 5 times over the course of the last years, and 4 of them don't run through the verifier, obviously). They're also somewhat documented in the wiki of the libbpf project, without further explanation on why or what [7]. Without that bootlin repo I still would have no idea other than how to make a print inside a "kretprobe". Anything more advanced is totally undocumented.

- OpenSnitch even has a workflow that copies their own codebase inside the kernel codebase, just to make it compile - because all other ways are too redundant or too broken. Not kidding you. [8]

Note that none of any BPF related projects uses any kind of reliable version scheme, and none of those project uses anything "modern" like conan (or whatever) as a package manager. Because that would have been too easy to use, and too easy on documenting on what breaks when. /s

Overall I have to say, BPF was the worst development experience I ever had. Writing a kernel module is _easier_ than writing a BPF module, because then you have at least reliable tooling. In the BPF world, anything will and can break at any unpredictable moment. If you compare that to the experience of other development environments like say, JVM or even the JS world, where debuggers that interact with JIT compilers are the norm, well ... then you've successfully been transferred back to the PTSD moments of the 90s.

Honestly I don't know how people can use BPF and say "yeah this has been a great experience and I love it" and not realize how broken the tooling is on every damn level.

I totally recommend reading the book [9] and watching the YouTube videos of Liz Rice [10]. They're awesome, and they show you how to tackle some of the problems I mentioned. I think that without her work, BPF would have had zero chance of success.

What's missing in the BPF world is definitely better tooling, better error messages (e.g. "did you forget to do this?" or even "unexpected statement" would be sooooo much better than the current state), and an easier way to debug an eBPF program. Documentation on what's available and what is not is also necessary, because it's impossible to find out right now. If I am not allowed to use pointers or whatever, then say so in the beginning.

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

[2] https://github.com/libbpf/libbpf

[3] https://github.com/xdp-project/xdp-tools

[4] https://github.com/cilium/ebpf/

[5] https://github.com/cilium/ebpf/tree/master/examples/headers

[6] https://elixir.bootlin.com/linux/latest/source/tools/testing...

[7] https://github.com/libbpf/libbpf/wiki/Libbpf-1.0-migration-g...

[8] https://github.com/evilsocket/opensnitch/blob/master/ebpf_pr...

[9] https://isovalent.com/learning-ebpf/

[10] (e.g.) https://www.youtube.com/watch?v=L3_AOFSNKK8

Hey there! Of course. There are a few good examples here and here. Yes, they're specific tools (which I, by the way, do recommend), but you can have a look at the BPF code here as well.

ebpf-go by Cilium which is a pure-Go library to read, modify and load eBPF programs and attach them to various hooks in the Linux kernel.

cilium is probably the best one that has the widest use and is supported by cloudflare.

libbpfgo ebpf

Go library that provides utilities for loading, compiling, and debugging eBPF programs [https://github.com/cilium/ebpf]

The error I get is "could not import github.com/cilium/ebpf (no package for import github.com/cilium/ebpf". I have the variable lsp-go-library-directories-include-go-modules set to t and the directory $GOPATH/pkg/mod/github.com/cilium/[email protected] exists and has the correct code in it. What am I missing to make LSP pick up these libraries?

If you want to run something like monitoring or diagnostic code, maybe you could achieve something like this with eBPF (see https://github.com/cilium/ebpf).

It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]).

[0] https://github.com/illumos/illumos-gate

Nobody's paid to have it pass Open Group Unix Branding certification tests

https://www.opengroup.org/openbrand/register/

so it can't use the UNIX™ trade mark.

But it's got the AT&T Unix kernel & userland sources contained in it.

PDP-11 Unix System III: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...

IllumOS: https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...

> it seems like this bug might actually date back to the very beginning of ZFS with Sun

Looks like you might be right about that. The oldest commit referenced in the fix [0] was from 2006[1], which was just months after Sun released ZFS.

[0] https://github.com/openzfs/zfs/pull/15571

[1] https://github.com/illumos/illumos-gate/commit/c543ec060d

It could be good for in memory stores / log-structured merged trees / other data store applications although it isn't used much now-days. I find them simpler to implement and understand than red-black trees -- although that's a matter of taste I suppose. They beat red-black trees in read-heavy loads (i.e. writes / updates are more costly for AVL trees than for Red-Black trees although they beat R-B trees for read-heavy loads). You can find another implementation in Illumos (an open source Unix operating system) available here: https://github.com/illumos/illumos-gate/blob/master/usr/src/...

It's high time that the Illumos developers patched https://github.com/illumos/illumos-gate/blob/master/usr/src/... and https://github.com/illumos/illumos-gate/blob/master/usr/src/... to just set the error flag and return, and made the #ifndef TIOCSTI path in https://github.com/illumos/illumos-gate/blob/master/usr/src/... the only path.

Because by the looks of https://github.com/illumos/illumos-gate/blob/7c478bd95313f5f... the C shell was fixed years ago.

People are still actively working on Illumos. The last change was yesterday morning.

* https://illumos.org

People are still actively working on MirBSD. There's a CVS commit account that can be followed on the FediVerse.

* http://www.mirbsd.org

It's DragonFly BSD, not Dragon BSD, and the irony of that is that you missed FreeBSD, which is of course still going.

* https://dragonflybsd.org

* https://freebsd.org

As is GhostBSD, which tracks FreeBSD.

* https://ghostbsd.org

HardenedBSD is still going. Shawn Webb regularly talks about it on the FediVerse.

* https://hardenedbsd.org

Its successor is still out there: Illumos. Though it seems to be mainly focused on backwards compatibility for existing custom applications as it still enforces things like an 8 character username limit.

> Since then, illumos has rewritten all those components

But apparently kept the same license?

>> Most of the existing code is licensed under the CDDL and we expect new code will generally be under this license as well.[0]

[0] https://github.com/illumos/illumos-gate