[cryptonector]

OK then! Back to C it is I guess. More seriously, we're talking about the Linux kernel here: it's written in C, and there's some momentum to write new code in Rust. You're asking for the moon, but you may have to settle for a picture of it.

[mananaysiempre]

I’m not talking about writing parts of the kernel in Rust. I‘m not even talking about using Rust inside the eBPF implementation specifically. In either case that’s replacing C with Rust, and if that’s what you want, sure, knock yourself out. In the spirit of full disclosure, I’ll admit to not being a fan, but it’s still entirely plausible and one can seriously argue it’d be an improvement.

But what TFA talks about amounts to replacing the eBPF verifier with (a blessed userspace version of) the Rust typechecker—dragging the rest of the compiler along for the ride—and that just feels like a downgrade in almost every respect. It’s humongous, it requires strange contortions due to not fitting in the kernel, it implements a comparatively very complicated spec, that spec is not written down, etc. The eBPF machine is not perfect, especially (as the authors point out) when you account for the “helpers“, but it mostly avoids these downsides. It’s not the moon—it’s already there.

[lcvw]

You can write ebpf programs in rust. Bpftrace generates programs from an awk like language, you can make the program however you want. Solana does it with rust, I don’t know what it gains you though given the verifier protecting you from most of the pitfalls of C.

[rurban]

Back to dTrace would be the obvious solution. Only OracleLinux has that.

Seemless probes across the kernel, libs and user-facing app.

No arrays.

Works for decades, but linux devs thought it they could do better.

[cryptonector]

Yes! But, NIH. Hmm, well, then again, BPF is NIH..