This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Ksummit-2008-discuss] DTrace
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