Re: [Ksummit-2008-discuss] DTrace

[Theodore Tso <tytso at mit dot edu>]

On Sun, Jun 29, 2008 at 09:04:23PM -0400, Frank Ch. Eigler wrote:
> * tapsets
> 
>   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.

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?  Is there any documentation or example usage scenarios for
these tapsets?

> * 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.  And it's not obvious what needs to be done with
for example the modules files, especially if they've been stripped so
they will fit into the /boot partition.  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.  I'm sure it's blindly obvious to a Systemtap
developer, but it isn't for someone who is just getting started with
Systemtap, and runs into one brick wall after another.

> * 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 seems to imply that you have to install the
elfutils globally, and I've been hesitant to do this lest it break
things that aren't expecting the latest bleeding edge library.  (I
have no idea whether the elfutils library developers worry about ABI
compatibility for applications dynamically link with the
system-provided elfutils library.)

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, or if you could download the patched elfutils library
into some directory in the Systemtap sources, and if present, the
build system would automatically use them.  This sort of minor thing
makes life much simpler for people who are trying to pull down the
latest Systemtap tree, especially 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.

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

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

						- Ted