What do you mean? The source is all open, and the bytecode format is well documented. There's nothing stopping anyone from writing their own with different semantics.
There's no doc on my work as it's private jerk offy personal project that I work on when I get tired of jira tasks and process.
You can patch your kernel, or write your own vm. BPF is ultimately just a kernel module under Linux. My vm runs in kernel space just fine as well (but is built on something that looks more like sel4 rather than Linux on the inside).
If you provided enough of std, or ported that VM to no_std that rust vm would work just fine in the kernel too.
I feel like we're talking on two different levels here.
It's sort of like how Oak was this neat virtual machine for running on a early 90s PDA prototype. Then the writers of that VM realized that they had written a really general purpose VM, cleaned it up and released the first Java.
This general of a VM (talking about eBPF now) hasn't been a first class citizen of a mainstream kernel before. The devs are taking a very cautious approach (as they should), but ultimately eBPF is way bigger than a tracing tool. I wouldn't be surprised to see nearly everything you currently do with a kernel module ultimately being allowed by eBPF too. Maybe more like emulating other OS's kernels as easily as you'd start another container.
There's no doc on my work as it's private jerk offy personal project that I work on when I get tired of jira tasks and process.
Edit: here's an example of one someone did in rust https://github.com/qmonnet/rbpf