> system tap, ktap, lttng, ftrace, etc

That's why I'm talking about NIH.

Even with ebfp, they intentionally choose different tracing syntax (just look at it, it's comical). Didn't use ready-to-use CTF. Etc etc etc.

The BPF people cannot be blamed for not using CTF. Even if it had been relicensed to the GPLv2 way back in 2005, until recently (https://github.com/oracle/libdtrace-ctf release 1.0 or 1.1) it was impractical to use CTF on larger projects because the file format could only encode a strictly limited number of types (2^15 in each of a parent and child container): it had a lot of related limitations as well, but that was the big one. This is not enough for a largeish enterprise kernel, even assuming that you share types used by multiple modules to reduce the overall type count. Also, BTF and CTF serve rather different purposes: CTF specifically encodes knowledge about C types, while BTF is specialized for encoding information about BPF maps. You can't use CTF for that: C doesn't even have a map type, nor anything like one, and the bits CTF spends on things like the details of floating-point formats are wasted on BPF.

As for the other part... obviously, as someone working on DTrace and using it ever more, I think it does hold value in its own right. It operates at a different level of the stack from BPF, in any case: it's a user-facing tool like a kernel-level awk, which is nothing like BPF.

In my opinion, saying that DTrace doesn't hold value because of BPF is like saying that C doesn't hold value because ARM assembly language exists as well as x86 (in this metaphor, C == DTrace, ARM assembly language == BPF, x86 assembly language == DIF, the DTrace intermediate format). It certainly seems possible to replace the DIF portion of DTrace with BPF, but this will not obsolete BPF nor DTrace: instead, DTrace will drop DIF and the DIF interpreter and build on BPF, generating BPF instruction streams the way it now generates DIF instruction streams. We get to improve BPF if needed and drop a redundant interpreter and BPF tracing gets a hopefully-nicer user interface in the shape of DTrace, and wider usage. Win-win!

(I'm not doing most of the work on this, so my opinion is far from authoritative, but I did do a preliminary experimental conversion of the hand-rolled DTrace code generator to emit BPF instructions instead, and it seemed perfectly practical: the two encodings are remarkably similar, and BPF is pleasant to generate, as such things go. That's only a small part of what needs doing, of course...)