Ask HN: How is eBPF a big deal?

It's a scripting language for the kernel (well, a language VM). There's something like 2500 different tracepoints you can attach scripts to, in addition all of network I/O. The programs you load with eBPF are very unlikely to disrupt the system, because of the limitations of the eBPF verifier.

Other people are talking about observability stuff, but for comparison, we build features on it: https://fly.io/blog/bpf-xdp-packet-filters-and-udp/

eBPF gives access to kernel-level information that's normally hidden from userland tools.

For example, I once wanted to find out which processes were sending out DNS queries.

It sounds like a simple problem but common tools like netstat or wireshark can't tell you the process which sent out a DNS query, only the sending port.

The reason is that the sending port is a short-lived randomly selected ephemeral port which the kernel opens, sends a quick chirp of data and closes within milliseconds. The sending process isn't traceable even using more complex tools like strace or auditd.

I used eBPF / bcc APIs to instrument a kernel-level function and data structures in UDP networking code and report the PID and port every time a DNS query is sent out.

It's like attaching a user-friendly debugger to large portions of the linux kernel.

Not sure if this is jargon-free enough, but maybe it helps: https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst...

Safe. Low impact. Kernel level observability.

You’ve not been able to get all 3 of those at the same time.