Re: [Ksummit-2008-discuss] DTrace

[fche at redhat dot com (Frank Ch. Eigler)]

Evgeniy Polyakov <johnpol@2ka.mipt.ru> writes:

>> > We don't add kernel interface for out of tree modules.
>> 
>> 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.

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.


>> > 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?


- FChE