[rurban]

The 2 major problems (ie the Elefant in the room) compared to DTrace are missing:

1. security: eBPF still supports arrays and and is therefore inherently insecure to be used in the kernel. DTrace didn't support that feature on purpose and not because they couldn't do it. see spectre/meltdown.

2. availability: eBPF probes only work within the kernel. DTrace extends the same interface to the libc level and the user space level. you can trace not only kernel calls, also lib calls and with its high-level language support (Java, python, perl, ruby,...) into userspace. Linux-only eBPF will never be able to support that seemless integration. thanksfully we now have Oracle Linux with proper DTrace support on Linux.

[brendangregg]

1. I'd say that the other way around: eBPF has already been hardened in a post spectre/meltdown world (see lkml), and I'm not sure DTrace has had the same level of security attention.

2. That's inaccurate, see the bpftrace docs for uprobes and usdt.

[efefef3]

Hmm, looks like you are missing some crucial details, eBPF has the same mitigations to the CPU bugs in place as the rest of the kernel (e.g. retpolines on tail calls, index masking for arrays, sanitation of speculative store bypass, etc). Also, eBPF probes do not only work in the kernel but user space as well via uprobes as one example.

[rurban]

Of course they ran after possible array problems post-spectre, but nevertheless it still allows precise timings on anything cache related. it's still highly insecure and needs to be turned off in production. and this is where it makes sense to use.

2nd: do you see uprobes supported anywhere? I still can only use DTrace with high level languages. and I wouldn't use this island solution anyway. DTrace works everywhere, now even on windows. eBPF is Linux-only. And should have stayed netfilter only BTW.