Re: [Ksummit-2008-discuss] DTrace

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

On Sun, Jul 06, 2008 at 02:00:03PM -0400, Frank Ch. Eigler (fche@redhat.com) wrote:
> >> That is a specific example of an attitude that I hope will be
> >> reexamined if y'all want to support dtrace-level introspection.
> >
> > I believe the only answer you will get is 'no'. Both for dtrace-like
> > stuff and ability to add unmaintained interfaces into the kernel.
> >
> > Out-of-tree stuff can appear and disappear, change its internal
> > structures, API, ABI [...]
> 
> 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.

> 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.  We have helped promote a
> systemtap-neutral instrumentation mechanism (markers), along with a
> project with a near-decade history of stable instrumentation (ltt/ng),
> and one can see the progress (?) that this has made even since Karim's
> "emperor is naked" note two (!) years ago.

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.

> >> > And thinking about it - having to compile out of tree kernel modules
> >> > on the fly to trace user space processes is just braindead.
> >> 
> >> I gladly grant "counterintuitive", especially if one's intuition is
> >> limited to probing just one's own pet user-space process.  It is a
> >> different matter when one needs to seamlessly probe a mixture of
> >> kernel activities, daemons, and user processes.
> >  
> > Out of curiosity, how in the hell administrator or any other non kernel
> > hacker person needs to have ability to tap into userspace process via
> > kernel module?
> 
> Think about how a non-intrusive system-wide probing must work, if it
> is desirable not to interfere with e.g. thread scheduling or VM state.
> Specifically, if we don't want to context-switch from threads (thereby
> interfering with contention effects we may want to measure), nor page
> data in/out just to satisfy probe data (thereby generating more I/O
> and associated distortions).  It seems only kernel-side code can do
> all of that.  Do you have a better suggestion?

Hmmm... Utrace suddenly stopped to work?
Even ptrace will work in described cases, if requested data is
accessible from userspace. Not sure about VM states, but kernel hides
this data on purpose, if it does need to be viewed from userspace, you
can extend statistics.

And is it really much simpler to use dtrace scripts (btw, does
systemtap has the same complexity of script writing?) for that?

-- 
	Evgeniy Polyakov