How would other subsystems use the safety of the BPF program - which I assume is the safe VM you mention? Do they have to assume that the network stack may not halt and have special code for it or sth ?
eBPF doesn't _have_ to use the network stack at all. So imagine i2c devices that get pulled out of the kernel. KVM drivers for top half of MMIO so KVM only needs half the number of context switches. Audio DSP kernels that run at interrupt time for super low latency. Really almost any interesting real time work.
Etc.
I thought eBPF programs run inside the kernel. Or are they _from_ userspace, run inside the kernel and so provide efficient into-kernel calls as well as direct access to certain _allowed_ hardware? I hope I’m not riding around semantics, sorry if I do.
They are programs, provided by user space, that are sandboxed to run safely in kernel space. Anything that isn't a RISC-esque instruction in BPF is a jump to a kernel function, and each flavor of BPF (BPF_PROG_TYPE_*) has it's own table of allowed functions. Most of the program types that are mainlined call functions in the net stack, but that's not intrinsic to the idea of BPF.
So in the I2C case, I could see device drivers that get called to handle the weird things that I2C devices do where you're not really sure until master interrupt time exactly what needs to happen next and you need to make a real time decision. So a BPF program that implements a state machine and is run directly from the master interrupt could be more performant and more power efficient than doing it in user space, and safer than doing it in kernel space.
