Re: [Ksummit-2008-discuss] DTrace

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

On Sun, Jul 06, 2008 at 10:23:08PM +0400, Evgeniy Polyakov wrote:

> > Yes, well, it turns out that the number of systemtap-specific kernel
> > interfaces we have requested is ... precisely ... zero.
> 
> Well, in the mail you replied to there was objection to add new
> interfaces.

That just illustrates the imperfect information floating around.


> > We have on occasion asked that some established module interfaces
> > simply not be *unexported*, but almost all of those requests have been
> > turned down, requiring us to kludge.  [...]
> 
> Unexporting some things allows to change them in order to fix some bugs,
> create better abstraction, introduce new feature... Having all calls
> forever does not provide any gain to the kernel, instead project can be
> pushed into the kernel, so anyone would win.

OK, so you think systemtap should go into the kernel ...


> > Think about how a non-intrusive system-wide probing must work,
> > [...]  It seems only kernel-side code can do all of that.  Do you
> > have a better suggestion?

> Hmmm... Utrace suddenly stopped to work?

(I assume you know that utrace is a kernel-side API.  You may realize
is that we are using it (via another layered module uprobes) to place
probes into user-space programs.)


> Even ptrace will work in described cases, if requested data is
> accessible from userspace. [...]

... but now systemtap stay out to userspace?  I don't understand.


> And is it really much simpler to use dtrace scripts [...] for that?

Simpler than what?  A userspace debugger that messes with thread state?


> (btw, does systemtap has the same complexity of script writing?

If you point out an example of what you consider a complex dtrace
script, I can try to answer that.


- FChE