Re: [Ksummit-2008-discuss] DTrace

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

Hi -

On Mon, Jun 30, 2008 at 02:19:59PM -0400, Theodore Tso wrote:
> [...]
> >   Theodore is mistaken that we are deflecting the job of tapset (probe
> >   macro; abstracting architecture and kernel version-change -
> >   $foo->bar->baz, function names) authorship.  We have asked for help,
> >   and have received a little, but the group has in fact authored a
> >   growing collection of this stuff.
> 
> Well I've heard the line that it's up to the kernel subsystem experts
> to write tapsets from Ulrich Drepper (on the ksummit-2008-discuss
> list) and from Ananth N Mavinakayanahalli (private communication) so I
> think it's fair to say that at least some people associated with
> Systemtap have been placing the blame for the lack of tapsets on the
> kernel developers.

We wouldn't talk about blame.


> As far as the growing collection of this stuff?  Where is it?  Do you
> mean in the tapsets directory of the systemtap sources in the git
> repository?  

Yes.

> Is there any documentation or example usage scenarios for these
> tapsets?

Yes, documentation - where exists - is in man pages (stapprobes, ...);
sample usage is in the example scripts, wiki, or the test suite itself.


> > * debuginfo
> > 
> >   Yes, it's very helpful & necessary if one wants to place probes at
> >   just about any statement and extract just about any data value.
> >   It's the same prerequisite that crash or kgdb would have, since we
> >   operate at a similar level of object/source code visibility.  Other
> >   distros are learning to package this admittedly bulky data up, so
> >   it'll be a matter of a largish download for distro users. Kernel
> >   developers will of course have the data generated locally already.
> 
> The problem is that kernel developers are often juggling multiple
> kernels, so kernel developers need to learn how to package up this
> bulky data as well.

They shouldn't have to repackage it at all - just leave it in the
build tree.

> It would be useful if
> http://sourceware.org/systemtap/wiki/SystemTapWithSelfBuiltKernel
> was a bit more explicit about exactly what SystemTap expects to find
> in SYSTEMTAP_DEBUGINFO_PATH.  [...]

That's a good point.  I'll make sure that the recipe for self-built
kernels is more complete.


> > * systemtap building
> > 
> >   The only thing unusual with building the thing is the use of the
> >   elfutils library to parse elf/dwarf data; links to that are provided
> >   and one can link to a private copy if the system lacks it.

> So how do you link to a private copy?  There's nothing in the wiki
> that describes this.  [...]  It would be nice if the Systemtap
> libraries had some provision where you could either point to a
> source directory where the patched elfutils libraries had been
> placed, and automatically used them for static linking,

That's exactly what the "--with-elfutils=DIRECTORY" systemtap autoconf
option does.

> [...] since the Wiki is filled with assertions (echoed by Ulrich in
> the recent ksummit-discuss thread) about how Systemtap is a fast
> moving project, and why it's absolutely necessary to grab the latest
> bleeding edge sources from the git tree.

That's been generally true - but that does not apply to elfutils.
Some of us run with rather old elfutils just fine.

> I'm willing to send patches for this sorts of usability issues if
> it's likely such patches would be accepted...

We would welcome any help with this stuff.

> > * systemtap releases
> > 
> >   True, we've been spotty with formal releases, though they are
> >   archived and available, and we're moving to a more regular release
> >   schedule very shortly.  The weekly snapshots have been good (except
> >   a recent unfortunate regression that hits 2.6.25 kernels
> >   particularly badly - that's holding up the new release plans).
> 
> Does the regression hit 2.6.26-rc8 kernels?  (i.e., should I not
> bother trying Systemtap until this gets cleared up, lest I waste hours
> and hours again getting frustrated?)

Early data suggests it's better under 2.6.26, so I recommend trying it
just once (don't spend hours).  If it fails, then please wait until
the 0.7 release -- or just try the older 0.6.2, which will almost
certainly work fine for you.

- FChE