This is a pretty cool project and I think the comments here are being overly negative. Sure, removing the constraints that the eBPF verifier requires might encourage more complex and less performant code - but this is just another tool in the toolbox. For truly production systems, I can see the battle-tested eBPF being the top choice over a dubious kernel extension. But for quick prototyping? Rex can probably take the cake here once the project matures a bit more.

▲

vlovich123 4 hours ago | parent | next [-]

It’s not about battle testing but that eBPF is has specific restrictions that a) won’t lock up your kernel b) won’t cause a security exploit by being loaded. Now Spectre throws a wrench in things, but the framing is weird; why compare it to eBPF vs just making a mechanism to load kernel modules written in Rust.

	▲	mirashii 2 hours ago \| parent [-]
		> why compare it to eBPF vs just making a mechanism to load kernel modules written in Rust. Because it's not just a mechanism to load kernel modules in Rust, it's specifically a mechanism to load them in the same places that ebpf programs are loadable, using the existing kernel machinery for executing ebpf programs, and with some helpers to interface with existing epbf programs.

▲

otabdeveloper4 4 hours ago | parent | prev [-]

Sorry dude, I don't want you guys vibecoding my kernel modules while spouting cargocult platitudes that "it can't have bugs, it's written in Rust".