Re: [Ksummit-2008-discuss] DTrace

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

Hi -


On Sun, Jul 06, 2008 at 02:34:14PM +0200, Christoph Hellwig wrote:

> > For systemtap's purposes, that is sufficient.  Our probes are meant to
> > run non-intrusively (they do not mess with user thread scheduling,

> But that's not what matters.

Really?  Exactly what kinds/degrees of intrusiveness do you believe
would be acceptable, and still be dtrace-level useful, and how did you
come up with that list?

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


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


> > > [...] For complex traces doing this in userspace is for sure a better idea.
> > 
> > Can you elaborate upon this more complex scenario?
> 
> For complex traces you basically want a ptrace without the signal mess.
> See the utrace list for some design ideas.

I'm well aware of the utrace list traffic, and that describes a
low-level debugger interface API.  You're not describing a "complex ..
trace ...  scenario" -- i.e., the purpose that you imagine
ptrace-via-utrace is *the* appropriate solution for.


- FChE