This is an interesting perspective. I’ve never used dtrace, although I know a lot of fans of it, who didn’t like (what I thought was) the Linux equivalent, System Tap. There’s no mention of System Tap in this article. I wonder, are people writing eBPF stuff to do things one would use dtrace for on Solaris, completely orthogonally to System Tap? Or are System Tap and the eBPF framework integrated in some way?
SystemTap traces were originally compiled into kernel modules that were loaded on the fly for each invocation. Now there is a SystemTap backend that uses eBPF. But the momentum is now clearly on the side of eBPF, which is turning into a general-purpose in-kernel VM for doing all sorts of things, so there’s probably no need to learn SystemTap rather than bpftrace (the DTrace-like front end to eBPF).
This is an interesting perspective. I’ve never used dtrace, although I know a lot of fans of it, who didn’t like (what I thought was) the Linux equivalent, System Tap. There’s no mention of System Tap in this article. I wonder, are people writing eBPF stuff to do things one would use dtrace for on Solaris, completely orthogonally to System Tap? Or are System Tap and the eBPF framework integrated in some way?
SystemTap traces were originally compiled into kernel modules that were loaded on the fly for each invocation. Now there is a SystemTap backend that uses eBPF. But the momentum is now clearly on the side of eBPF, which is turning into a general-purpose in-kernel VM for doing all sorts of things, so there’s probably no need to learn SystemTap rather than bpftrace (the DTrace-like front end to eBPF).
(Edit) For example, see XDP, eBPF accelerated networking: http://blogs.igalia.com/dpino/2019/01/10/the-express-data-path/