I feel that this proposal defeats the entire purpose of ebpf. The point is to have a bytecode language that can do simple processing in the kernel. This code is frequently generated adhoc, such as with bpftrace. I don’t like all the limitations that currently exist in bpf, but just replacing it with rust and signature verification basically turns this into kernel modules all over again.
There's nothing really "simple" about eBPF bytecode; it's a full fledged ISA, so much so that the idiomatic way to build eBPF programs is to compile them from straight C with clang.
Comments
I feel that this proposal defeats the entire purpose of ebpf. The point is to have a bytecode language that can do simple processing in the kernel. This code is frequently generated adhoc, such as with bpftrace. I don’t like all the limitations that currently exist in bpf, but just replacing it with rust and signature verification basically turns this into kernel modules all over again.
There's nothing really "simple" about eBPF bytecode; it's a full fledged ISA, so much so that the idiomatic way to build eBPF programs is to compile them from straight C with clang.