5 ms·
> BPF programs are written in C, and compiled into BPF bytecode. Like other bytecode instruction sets, BPF programs are platform-independent and just-in-time (J
by bheadmaster 4y ago
> BPF programs are written in C, and compiled into BPF bytecode. Like other bytecode instruction sets, BPF programs are platform-independent and just-in-time (JIT) compiled.
That sounds similar to what Inferno was doing. Though I'm unaware whether Inferno did it in kernel space, but PhantomOS definitely did - their argument was that, since you can't run native code directly, only through the bytecode, memory safety can be achieved by simply not giving a program any reference to a memory address it's not supposed to access. Apparently, this approach achieves memory protection without using an MMU.
Would be cool to see if Linux eventually goes down that path.
- pjmlp 4y agoInferno uses C (Plan 9 C dialect) for the kernel and Limbo for the complete userspace, with exception of some C libraries like Tk for the GUI. DisVM runs in userspace. https://github.com/inferno-os https://github.com/inferno-os
- amelius 4y agoJava did this in the 90s. Not sure why we need yet another bytecode format.
- bheadmaster 4y agoBytecode format itself is not interesting (PhantomOS runs Java bytecode, Inferno was a competitor to Java in the 90s), but the way it is executed. Java runs bytecode in a VM as a userspace process, eBPF runs it in kernel space. That in itself is interesting.
- amelius 4y agoDoes running in kernel space justify an entirely new bytecode?
- bheadmaster 4y agoJustify? I don't know. Require? I also don't know, but intuition tells me that it does, at least in the case of Linux.