Re: [Ksummit-2008-discuss] DTrace

[ebiederm at xmission dot com (Eric W. Biederman)]

James Bottomley <James.Bottomley@HansenPartnership.com> writes:

> I've also found it very easy to crash the system under probe if you use
> the wrong build tree for the running kernel (not a problem, I know that
> enterprise customers run into, but a common one for kernel developers).
> Since we have a kernel build version that increments with every build,
> it would be useful to sanity check the one systemtap pulled out of the
> debug with the one in the running kernel.

Interesting.  I wonder how much the DTrace in kernel interpreter
protects them from that.

>> * dtrace "just works"
>> 
>>   Yeah, so I hear, but think about how different their target
>>   environment is.  Their kernel hardly changes (several fixed APIs,
>>   ABIs): this has huge implications.  Their kernel was willing to
>>   insert probes (~ markers), a bunch of build system changes (debug
>>   info subset transcribing).  Here in linux land, we suffer
>>   multifaceted tensions and it is hard to go toward a goal without
>>   obstructions (well-meaning as they may be).
>
> The goal has to be well articulated and agreed to.  Open source is rapid
> at progressing towards common goals ... it's when the goals aren't
> common that progress gets bogged down.

In addition to a well articulated goal.  A feature poor implementation
that works and gives people lots of itches to scratch helps.

What is the goal with SystemTap?

The goal with Dtrace (and I am badly paraphrasing) is to allow a system
level look into what is happening.

There was a talk at OLS in 2006 entitled "Why user space sucks."
Which pointed out all of the silly things that were happening during
boot from a system level perspective.  How do we make that kind of
tracing easy with SystemTap?

Those are the interesting questions, and in general they shouldn't
need complicated tapsets and other prebuilt knowledge.  It is the
global view of how things are connected that looks most interesting.

Eric