Hacker News Reader

Comment by stefan_ | Hacker News Reader

eBPF are vendor kernel modules on steroids: now instead of getting compile failures trying to build your out-of-tree module, your stuff just blows up at runtime.

View on HN

eBPF has been invaluable in my field (low-latency linux applications) and it changed a lot.

If you had problems working with kernel modules before, you probably should expect struggling with writing correct code for eBPF too. It's not for everyone.

Can you share the sort of things you've been doing with it?

Most recently I used ebpf to track which other threads were stealing cpu time (and how much) from my latency sensitive cpu-pinned thread. You can do almost anything, the level of introspection into the kernel internals is amazing.

But, you have the huge advantage that if they crash, they don't bring down your system.

This seems to be around the wrong way.

For both traditional kernel modules and eBPF programs, you compile the code ahead of time. For kernel modules, if you have a bug, you load it into the kernel and the kernel hard crashes at runtime. For eBPF programs, the kernel will reject the program before you inject it.

In practice to deploy eBPF programs, you end up adding the kernel verification step into part of your CI/dev workflow so that by the time you ship your programs, you know that they will safely load and safely run in real environments.

Pfft, had that with 1987 Amiga 1.3, took Linux another 26 years to get there.

Tioga editor in Xerox's Cedar already had a native structural active document capability back in 1987, but the most successful commercial Microsoft Office applications with billions of dollars budget still do not have this capability, your point exactly?

Reply on news.ycombinator.com