The state of eBPF

Uh, that project literally *uses BPF in the kernel* and has a WASM runtime in user space? That's not even remotely the same thing as having a WASM engine itself run entirely in the kernel. Seriously, stop sending hypothetical examples that show how easy something _could_ be. It's worth literally nothing until you have actual code.

>> I've done cursory readings about WASM. For example, I understand that infinite loops are possible in WASM.

>What did I say about educating you?... OK, this is the last one that is for free.

I was basing this off of Mozilla documentation: https://developer.mozilla.org/en-US/docs/WebAssembly/Refe.... What you're describing below sounds like some likely-inappropriate-for-kernel-space detail of a specific WASM runtime. I may be wrong about that being specific to a WASM runtime though, I freely admit that I'm not at all a WASM expert (unlike your willingness to admit that you know very little about BPF).

>WASM runtimes support a concept called "metering". You can allocate a certain amount of "fuel" to a WASM program, and the runtime will either suspend or terminate the program, once the fuel is exhausted. Fuel accounting is updated at backbranches and function calls, so this makes arbitrary loops safe. Example: https://github.com/bytecodealliance/wasmtime/blob/main/ex...

Ok, so how does that work if you have a synchronous program that can't be interrupted? Or if you're in an RCU read region? All of these little details that matter a lot in kernel space that you can just nuke away in user space.

>Alternatively, it's possible to terminate/suspend a WASM program simply via an epoch counter mechanism ( https://github.com/bytecodealliance/wasmtime/blob/main/cr... ), that can be triggered by a timer on timeout. Example: https://github.com/bytecodealliance/wasmtime/blob/main/ex...

Ok, so what does the runtime do if it's running in an NMI handler? Or even just with IRQs disabled? No timer anymore. I guess the WASM will have special logic that verifies that a WASM program running in those contexts is safe without timers?

Maybe there are answers to these questions, but they require actual code instead of hypotheticals and links to things that work in some user space runtime. Point me to as many GitHub repos as you want. They mean literally nothing until you have working code that's not broken and actually runs in the kernel.

>As a result, eBPF had to add full-blown exceptions to support error conditions and cancellations: https://elixir.bootlin.com/linux/v6.8-rc1/source/kernel/b...

Notice how you linked actual upstream source code? As opposed to all of your examples of links to either defunct unsafe projects, or WASM projects that run in user space and literally use BPF under the hood to run in the kernel? And yes, I'm well aware of exceptions. I also recall your totally level-headed comment in [0] where you decried how useless it was.

[0]: https://lwn.net/Articles/938435/

>Guys, really? You are now adding freaking exceptions.
>This is not just "feature creep", it's a "feature runaway train at 100mph".

Imagine my shock when I saw that Cyberax was upset that someone had added an incredibly useful feature to BPF. If you hated it so much, why didn't you say anything on the mailing list? Oh, and here's another one:

>One of the bragging points of BPF was "but it always returns a value!", and that's why it's apparently better than WASM.
>With the addition of exceptions, this guarantee is lost.
>Not that it mattered either way in practice, but still. BPF is now just adding features without even considering their impact on the overall BPF model.

Sorry, what are you even talking about? You keep boiling BPF down to some very simple JIT thing and ignoring the extremely rich *Linux kernel* programming ecosystem of BPF that's far more robust than just "does it return a value". Also, things can evolve. Here, I recommend reading an article [1] that I wrote about the future direction of BPF.

[1]: https://lwn.net/Articles/909095/

Shocker, there's another Cyberax comment on that one too:

>Can we just switch from BPF to WASM?

You made that comment almost a year and a half ago. I wonder how many WASM-in-the-kernel patches you've sent to LKML since then?

>I'm not too invested in eBPF/WASM, but it's terrible to see a project keep digging themselves deeper into a hole.

It's abundantly clear that you're not invested in BPF based on how little you know about it, and how you never actually participate in any discussion forums where your contributions would be meaningful.

Anyways, I'm done with this convo. Feel free to send some patches upstream that actually add WASM to the kernel, and I promise you that I will give them a thorough and genuine review. Or if you'd prefer to keep spamming LWN with your hatred of BPF and your dreams of a hypothetical WASM utopia, go ahead.