From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3536 invoked by alias); 30 Jun 2008 19:27:09 -0000 Received: (qmail 3525 invoked by uid 22791); 30 Jun 2008 19:27:08 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jun 2008 19:26:43 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5UJQfK9031621; Mon, 30 Jun 2008 15:26:41 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5UJQee4002392; Mon, 30 Jun 2008 15:26:40 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.yyz.redhat.com [10.15.16.9]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5UJQ7oI026114; Mon, 30 Jun 2008 15:26:40 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 14AC68001FF; Mon, 30 Jun 2008 15:25:50 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id m5UJPYv9006503; Mon, 30 Jun 2008 15:25:34 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m5UJPXf1006502; Mon, 30 Jun 2008 15:25:33 -0400 Date: Mon, 30 Jun 2008 20:00:00 -0000 From: "Frank Ch. Eigler" To: Theodore Tso Cc: ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080630192533.GE21660@redhat.com> References: <20080630010423.GA7068@redhat.com> <20080630181959.GA7988@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630181959.GA7988@mit.edu> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00805.txt.bz2 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