[Ksummit-2008-discuss] DTrace

James Bottomley James.Bottomley at HansenPartnership.com
Sat Jun 28 06:31:53 PDT 2008


On Sat, 2008-06-28 at 06:14 -0600, Matthew Wilcox wrote:
> On Fri, Jun 27, 2008 at 08:38:39PM -0700, Ulrich Drepper wrote:
> > If we could get that level of collaboration we could quickly
> > get to the point where the kernel side of the probing is at least as
> > well supported as dtrace support for Solaris.
> 
> This is getting away from my original point.  We need to be able to
> profile userspace as well as DTrace does, ideally with the same probe
> annotations that dtrace uses.

Actually, I think is to the point:  Open source development proceeds by
a kind of magnetic abstraction; people see something and think "hey I
could use that" and promptly modify it so they can.  Although there are
differing opinions about what systemtap could and should do, it's clear
that it's not working incredibly well for its design space: the kernel,
so talking about extending it to userspace is a premature.

The topic therefore that would appear to be on point is fixing
systemtap.  Since I've been wading through it all week trying to fix a
simple variable dereference problem, I'll go back and take a look and
see if I can identify any other issues.  One immediate one I can see on
2.6.26-rc8 is that it's throwing lockdep errors because of some mismatch
between the kernel and the internal systemtap module building API.
Christoph Hellwig suggested on IRC when I asked that this is because the
entirety of the systemtap runtime should be in kernel (that's files
under /usr/share/systemtap/runtime, but what they mostly are are C
fragments used to insert probes and extract information), and looking
through it along with the problems it's causing, I think I'm starting to
agree.

James




More information about the Ksummit-2008-discuss mailing list