From: "Frank Ch. Eigler" <fche@redhat.com>
To: Theodore Tso <tytso@mit.edu>
Cc: ksummit-2008-discuss@lists.linux-foundation.org,
systemtap@sources.redhat.com
Subject: Re: [Ksummit-2008-discuss] DTrace
Date: Mon, 30 Jun 2008 20:00:00 -0000 [thread overview]
Message-ID: <20080630192533.GE21660@redhat.com> (raw)
In-Reply-To: <20080630181959.GA7988@mit.edu>
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
next prev parent reply other threads:[~2008-06-30 19:27 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-30 13:57 DTrace Frank Ch. Eigler
2008-06-30 19:00 ` [Ksummit-2008-discuss] DTrace Grant Grundler
2008-06-30 19:40 ` Theodore Tso
2008-06-30 20:00 ` Frank Ch. Eigler [this message]
2008-06-30 20:19 ` Theodore Tso
2008-06-30 21:12 ` Arnaldo Carvalho de Melo
2008-06-30 23:02 ` David Miller
2008-06-30 21:13 ` James Bottomley
2008-06-30 22:10 ` Frank Ch. Eigler
2008-07-01 2:42 ` Theodore Tso
2008-07-01 7:08 ` Roland McGrath
2008-07-01 10:15 ` Theodore Tso
2008-07-01 11:04 ` Sam Ravnborg
2008-07-01 12:13 ` Theodore Tso
2008-07-02 20:27 ` Sam Ravnborg
2008-07-01 20:06 ` Roland McGrath
2008-07-01 23:13 ` Theodore Tso
2008-07-02 2:23 ` Frank Ch. Eigler
2008-07-02 19:27 ` Frank Ch. Eigler
2008-07-02 21:40 ` Potential Systemtap topics for the Kernel Summit Theodore Tso
2008-07-02 21:51 ` [Ksummit-2008-discuss] " Jonathan Corbet
2008-07-02 23:41 ` Arnaldo Carvalho de Melo
2008-07-02 22:38 ` Masami Hiramatsu
2008-07-02 22:54 ` [Ksummit-2008-discuss] " Stephen Hemminger
2008-07-03 0:44 ` Ulrich Drepper
2008-07-03 1:02 ` H. Peter Anvin
2008-07-03 1:50 ` Theodore Tso
2008-07-03 1:51 ` Ulrich Drepper
2008-07-02 20:08 ` [Ksummit-2008-discuss] DTrace Joel Becker
2008-07-02 20:17 ` J. Bruce Fields
2008-07-02 20:41 ` Frank Ch. Eigler
2008-07-02 21:19 ` H. Peter Anvin
2008-07-02 21:30 ` Theodore Tso
2008-07-02 21:46 ` J. Bruce Fields
2008-07-05 9:46 ` Peter Zijlstra
2008-07-05 10:07 ` Christoph Hellwig
2008-07-05 12:12 ` Frank Ch. Eigler
2008-07-05 18:08 ` Christoph Hellwig
2008-07-05 13:50 ` James Bottomley
2008-07-05 18:08 ` Christoph Hellwig
2008-07-05 18:05 ` K.Prasad
2008-07-07 14:36 ` Christoph Hellwig
2008-07-07 17:44 ` K.Prasad
2008-07-05 12:34 ` Theodore Tso
2008-07-01 5:29 ` Ananth N Mavinakayanahalli
2008-06-30 19:59 ` James Bottomley
2008-06-30 23:52 ` Masami Hiramatsu
2008-07-08 23:32 ` Eric W. Biederman
[not found] <20080627150424.GB14894@parisc-linux.org>
[not found] ` <1214580213.3394.40.camel@localhost.localdomain>
[not found] ` <20080627155018.GC14894@parisc-linux.org>
[not found] ` <1214583502.7698.15.camel@weaponx>
[not found] ` <20080627163056.GB1416@lst.de>
[not found] ` <20080628072605.GA505@in.ibm.com>
[not found] ` <20080629084002.GA24131@lst.de>
[not found] ` <20080630051034.GA4970@in.ibm.com>
[not found] ` <20080630112913.GA18817@lst.de>
2008-06-30 19:27 ` Frank Ch. Eigler
2008-07-01 1:21 ` Jim Keniston
[not found] ` <20080706123414.GA9265@lst.de>
2008-07-06 15:47 ` Frank Ch. Eigler
2008-07-06 16:36 ` Evgeniy Polyakov
2008-07-06 18:05 ` Frank Ch. Eigler
2008-07-06 18:24 ` Evgeniy Polyakov
2008-07-06 21:46 ` Frank Ch. Eigler
2008-07-06 22:47 ` Karen Shaeffer
2008-07-06 23:15 ` Frank Ch. Eigler
2008-07-07 5:59 ` Evgeniy Polyakov
2008-07-07 11:19 ` Frank Ch. Eigler
[not found] ` <20080627182754.GB7549@mit.edu>
[not found] ` <1214597135.3394.82.camel@localhost.localdomain>
[not found] ` <aday74qlh08.fsf@cisco.com>
[not found] ` <4865B111.2040307@redhat.com>
[not found] ` <adavdzujh2u.fsf@cisco.com>
[not found] ` <20080704200055.GA11232@synapse.neuralscape.com>
[not found] ` <20080704224424.GA12454@synapse.neuralscape.com>
[not found] ` <1215273663.3439.34.camel@localhost.localdomain>
2008-07-06 23:33 ` Frank Ch. Eigler
2008-07-07 14:35 ` James Bottomley
2008-07-07 15:02 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080630192533.GE21660@redhat.com \
--to=fche@redhat.com \
--cc=ksummit-2008-discuss@lists.linux-foundation.org \
--cc=systemtap@sources.redhat.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).