I think comparing dtrace to eBPF is missing what makes eBPF great. dtrace is just one application that can be implemented using eBPF.
Your toolbox can be used to fix things, but eBPF is a factory for making new types of tools and toolboxes.
eBPF can be used to make small programs that run at tracing points, thus making dtrace. But it can also be made to make packet filter decisions (thus altering what happens), and with at least one network card that eBPF program can be pushed to the network card and filter before the packet even hits RAM, much less the CPU!
eBPF can run at socket init time, and set some default TCP tuning parameters.
Another comment in this thread asked if one can write a whole device driver in eBPF. The answer is actually not clear.
eBPF is more similar to "the ability to load kernel modules" than it is "a tracing framework".
Your toolbox can be used to fix things, but eBPF is a factory for making new types of tools and toolboxes.
eBPF can be used to make small programs that run at tracing points, thus making dtrace. But it can also be made to make packet filter decisions (thus altering what happens), and with at least one network card that eBPF program can be pushed to the network card and filter before the packet even hits RAM, much less the CPU!
eBPF can run at socket init time, and set some default TCP tuning parameters.
Another comment in this thread asked if one can write a whole device driver in eBPF. The answer is actually not clear.
eBPF is more similar to "the ability to load kernel modules" than it is "a tracing framework".