This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [Ksummit-2008-discuss] DTrace
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Christoph Hellwig <hch at lst dot de>
- Cc: ksummit-2008-discuss at lists dot linux-foundation dot org, systemtap at sources dot redhat dot com
- Date: Sun, 6 Jul 2008 11:46:12 -0400
- Subject: Re: [Ksummit-2008-discuss] DTrace
- References: <1214580213.3394.40.camel@localhost.localdomain> <20080627155018.GC14894@parisc-linux.org> <1214583502.7698.15.camel@weaponx> <20080627163056.GB1416@lst.de> <20080628072605.GA505@in.ibm.com> <20080629084002.GA24131@lst.de> <20080630051034.GA4970@in.ibm.com> <20080630112913.GA18817@lst.de> <20080630171246.GB21660@redhat.com> <20080706123414.GA9265@lst.de>
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