Sorry, this is going to be rather long for HN, but it's been bugging me for a while now, and this is a good opportunity to talk about it.<p><pre><code> Can't enhanced BPF do this too?
Yes, if you program it to. I feel like we've been waiting for
advanced tracing in Linux for years, and now two busses have
arrived at the same time. This overlap concern was raised and
discussed on lkml, and it was eventually deemed that hist triggers
was different enough to be included.
</code></pre>
This is what's wrong with Linux kernel development. We have pluggable subsystems like I/O scheduling or CPU scheduling where BFQ or BFS are not mainlined and have to live as external patchsets. Then we have more than a few competing tracing/probing frameworks all somehow magically in torvalds/linux.git despite their overlap and unfinished (partly experimental) state.<p>I used to think that Linux kernel development is about who comes up with good, working code, but more and more I'm starting to get the impression it's that you need to have the right connections for a competing implementation to land.<p>I won't argue that linux needs DTrace or a similarly coherent solution, although I absolutely believe that. However, seeing the impossible to explain difference in what experimental, half-implemented code gets mainlined and which widely used patches have to live outside the kernel, I cannot find another explanation than requiring the right street cred and connections for competing implementations to land. This is especially inexplicable for BFQ because it's a in an already pluggable system.<p>To be clear, I'm not referring to projects like GRsec whose maintainers are unwilling to split it into smaller chunks, and I'm primarily talking about simple things like BFQ, which has solved my global lockups during large (long) USB mass storage flushing. With BFQ, it's at most the application that called fsync() and the rest of the applications are still responsive.<p>With all that being said, the evolutionary style of kernel subsystem development doesn't work for everything, especially not for a DTrace replacement, which would do well by having a single well thought out design and broad availability of probes. While I can see that maybe people are afraid of Oracle patents, DTrace isn't complicated enough that a similar effort couldn't be implemented while keeping the same benefits. A simple transpiler for DTrace scripts can be more than sufficient if the syntax is also preferred to be different.<p>In summary, I don't understand how we have so many tracing system alternatives, experimental and unfinished as well, while a pluggable subsystem has only plugins personally accepted by that subsystem's maintainer.