"eBPF Documentary: An exciting train wreck in progress"<p>That would be a better title. eBPF started as a small extension to just be able to insert small trivial hooks. It's now basically a hacked-up broken WebAssembly clone, with zero forethought put into it. NIH syndrome at its worst.<p>It has recently grown unlimited loops with runtime metering, making the static verifier basically a worthless complexity. Before that, it had acquired exceptions and stack unwinding.
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.<p>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.
I've been hearing more and more about eBPF, especially here on HN.<p>I haven't yet watched the documentary so perhaps it is answered there. But, the analogy of JavaScript inside the kernel is great and I'm left wondering: what was the way to do it previously? Userland network tool? This standardizes on a interface to the kernel, not a language, right? Feels off to say it is JavaScript because that comes with a lot of baggage, but also (as a versatile and ubiquitous language) incredibly powerful and useful tool. Is that intentional by the author?
I was a little disappointed DTrace[0] was not mentioned at all. The instrumentation (not the SDN) isn’t novel, not even to Linux (DTrace is available on Linux - I understand licensing is at least questionable (for some distros), but that aside…). [1]<p>[0] <a href="https://en.wikipedia.org/wiki/DTrace" rel="nofollow">https://en.wikipedia.org/wiki/DTrace</a><p>[1] <a href="https://docs.oracle.com/en/operating-systems/oracle-linux/dtrace-tutorial/dtrace-tutorial-IntroducingDTrace.html" rel="nofollow">https://docs.oracle.com/en/operating-systems/oracle-linux/dt...</a>
eBPF modules can be closed-source, right? I can see a future where things like ZFS are paid eBPF modules, or games ship with proprietary anti-cheat eBPF modules.
I saw the airing of it at Kubecon -- also met the Finnish guy there in the video. I mistook him for another Finnish guy with blond hair. Didn't meet the Russian though.
It makes me wonder, what was the point of introducing Rust into the kernel when they already have eBPF?<p>Couldn't they have just used the existing eBPF compiler for creating safe kernel code?<p>Maybe the distant future of the Linux kernel is for almost everything to compile down to eBPF bytecode except the part that runs the bytecode.
ebpf seems to be a very interesting idea and have been experimenting with it. Still I find it weird that we're doing documentaries on software "frameworks"
It has always seemed quite obvious to me that dealing in machine code is a flawed approach for distributing software. At the most basic level, it entails giving someone else near unfettered access to the hardware of your computer and simply hoping that they do nothing malicious or malformed. Yet the software world as a whole seems continually shocked at the idea of using anything else. Perhaps someday we will learn this lesson in its entirety and begin to share code rather than blobs.
eBPF allows user-defined programs to run in the kernel.<p>This is huge for performance-sensitive code that executes against network packets: you don't have to context switch between kernel space and user space.<p>It's worth pointing out Solana's extreme competitive advantage over other chains is almost entirely due to it running on a variant of eBPF. †<p>This is an order-of-magnitude leap over other implementations and essentially the way you should do it, if you were to write it from scratch, aside from special purpose hardware fabrication.<p>† The second reason Solana is so fast is extreme parallelism: all accounts that are used in a transaction must be marked as either "read-only" or "writeable" before sending the transaction, allowing the runtime to parallelize all reads and only solve write contention when necessary.