Re: [Ksummit-2008-discuss] DTrace

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

Hi Frank.

On Sun, Jul 06, 2008 at 05:39:20PM -0400, Frank Ch. Eigler (fche@redhat.com) wrote:
> > 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 ...

Getting history of systemtap, I'm not sure it will be easily possible :)
But it is good project for overall Linux advertisement.
Personally I will not use it, since it is simpler (and very likely has
smaller performance overhead) to put various kinds of counters all over
needed places to get required statistics for hot pathes like VM and put
debug prints in the slow parts.

> > 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.)

And adds additional layer.
 
> > 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.

You asked how to get needed information. It can be accessed via ptrace,
so there is no need to have additional kernel module to get it.

> > And is it really much simpler to use dtrace scripts [...] for that?
> 
> Simpler than what?  A userspace debugger that messes with thread state?

Yes, ptrace approach is a bit messy, still there is utrace, and
now additional systap layer.

> > (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.

Things like  syscall::*read:entry, syscall::*write:entry
this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0;
I.e. 'this' and 'self' pointer

-- 
	Evgeniy Polyakov