4 ms·

ktap was really promising, but when eBPF began kernel integration, ktap development was postponed until it could be rewritten to use eBPF. eBPF itself is still

ktap was really promising, but when eBPF began kernel integration, ktap development was postponed until it could be rewritten to use eBPF. eBPF itself is still being integrated, part by part. I hope there's enough eBPF to restart work on ktap (or something like it) this year. ktap might have just missed out by unlucky timing. But hopefully we'll end up with a better tracer (ktap+eBPF) after the delay. I still want to see ktap finished. I've spent so many hours with Linux tracing (and talking to its developers), I think my next post will be "Choosing a Linux tracer (Jul 2015)", where I briefly summarize the current state of tracers, and make recommendations. I think it might work as a blog post, with a clear timestamp, since it's a topic that changes from month to month.

halayli 11y ago
I just wish they integrated dtrace into linux back in the day. It would have received a lot of support and improvement. Now every platform has its own complicated set of tools. Even dtrace on osx is not the same as dtrace on freebsd :(
- brendangregg 11y ago
  Linux integration would have been tricky, since Sun chose a license that they knew was incompatible with the GPL from the get go (http://www.slideshare.net/brendangregg/from-dtrace-to-linux/39 http://www.slideshare.net/brendangregg/from-dtrace-to-linux/...). But yes, would have been nice! :) Having such fragmentation in the Linux tracing space makes my job tricker, but for a lot of end-users it won't ultimately matter, given front-end analysis tools. In my current job, the team I'm on is building such a front-end analysis tool, and for a lot of end-users, they won't care much what the underlying tracer is, provided it meets their requirements.
  - halayli 11y ago
    agreed. Abstracting the tracers to provide similar information is a challenge. I had a plan once to create a SaaS around dtrace like tools but it's just too fragmented and couldn't find a common ground. Not to mention that most users don't have the proper debugging symbols around, nor the required kernels. So I bailed. :)

halayli 11y ago

I just wish they integrated dtrace into linux back in the day. It would have received a lot of support and improvement. Now every platform has its own complicated set of tools. Even dtrace on osx is not the same as dtrace on freebsd :(

brendangregg 11y ago
Linux integration would have been tricky, since Sun chose a license that they knew was incompatible with the GPL from the get go (http://www.slideshare.net/brendangregg/from-dtrace-to-linux/39 http://www.slideshare.net/brendangregg/from-dtrace-to-linux/...). But yes, would have been nice! :) Having such fragmentation in the Linux tracing space makes my job tricker, but for a lot of end-users it won't ultimately matter, given front-end analysis tools. In my current job, the team I'm on is building such a front-end analysis tool, and for a lot of end-users, they won't care much what the underlying tracer is, provided it meets their requirements.
- halayli 11y ago
  agreed. Abstracting the tracers to provide similar information is a challenge. I had a plan once to create a SaaS around dtrace like tools but it's just too fragmented and couldn't find a common ground. Not to mention that most users don't have the proper debugging symbols around, nor the required kernels. So I bailed. :)