[softirq]

The genius of ebpf is allowing for pluggable policy in a world where the kernel API is very slow to change and can’t meet everyone’s needs. Whether it’s how the kernel handles packets off the wire, how it controls traffic, scheduling entities, or instrumentation, ebpf lets you provide logic rather than turn a bunch of knobs or use a bespoke syscall that only handles one case. It also moves the processing logic to the data in the kernel rather than having the kernel have to do expensive copies to and from userspace.

ebpf isn’t really novel beyond the interfaces it provides. They are just kernel modules that have been vetted and are sandboxed. Inserting executable code has been part of the kernel since forever in module form and kprobes.

[bidandanswer]

> ebpf isn’t really novel beyond the interfaces it provides. They are just kernel modules that have been vetted and are sandboxed. Inserting executable code has been part of the kernel since forever in module form and kprobes.

This should be sung from the mountaintops. This concisely summarizes nearly everything that uninformed reader should take away from the comment section.

[yjftsjthsd-h]

> the kernel API is very slow to change and can’t meet everyone’s needs

Better yet - eBPF provides a stable ABI:) It makes things that were formerly kernel-internal possible to work with from a stable ~userspace interface.

[dilyevsky]

bpf tooling generally provides no stability guarantees when you interact with kernel primitives. See [0], for example. Tho things have improved somewhat with CO-RE

[0] - https://lore.kernel.org/lkml/93a20759600c05b6d9e4359a1517c88...

[stefan_]

I'm curious what this guarantee includes - the bytecode? Because the actual in-kernel eBPF API is famously unstable, with eBPF-based applications usually requiring a cutting-edge kernel version (for industry anyway). And of course the eBPF programs themselves rely on accessing structures for which no stability guarantees are made whatsoever.