Frank Ch. Eigler
fche at redhat.com
Mon Jun 30 12:25:33 PDT 2008
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
> Is there any documentation or example usage scenarios for these
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
> It would be useful if
> 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
> [...] 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.
More information about the Ksummit-2008-discuss