Comment by kragen

Oh right, the Plan9 thing was called rfork(), and it only had the flags argument. Thank you for the correction.

The bpf approach sounds interesting! It sounds like you're going to significant effort with RCU to avoid mutexes (for performance I assume?), but there are a few places that you still feel like such optimistic synchronization approaches would be unacceptably costly. What are they?

If you could get rid of them, you wouldn't need a statically declared locking order (and what does "statically" mean in a kernel interface to poke code into the kernel at runtime?)

I've been thinking it would be fun to try a pure capability language along the lines of E, but using pure optimistic STM instead of single threading. That would eliminate three of the biggest theoretical weaknesses of E: malicious code can deny service by infinite-looping a vat, so in practice you have to put potentially untrusted code in its own vat; the error handling is ad hoc and therefore probably prone to the kinds of devastating problems we've seen in the DAO ecosystem; and it doesn't scale on multicore. The E design, meanwhile, eliminates shared mutable data, which avoids a plethora of bugs and security problems L4 userland programs are likely to include.

Such a system of course doesn't need a kernel, but also isn't very suitable for running malicious machine code, and its runtime overhead is likely to be a lot higher than a traditional memory-protection-based system.

What's your main use case?