4 ms·
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
by stefan_ 7y ago
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.
- rhinoceraptor 7y agoBut, you have the huge advantage that if they crash, they don't bring down your system.
- bitcharmer 7y agoeBPF 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.
- bibabaloo 7y agoCan you share the sort of things you've been doing with it?
- bitcharmer 7y agoMost 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.
- smallstepforman 7y agoPfft, had that with 1987 Amiga 1.3, took Linux another 26 years to get there.
- teleforce 7y agoTioga 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?
- joestringer 7y agoThis 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.