From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21177 invoked by alias); 5 Jul 2008 12:34:14 -0000 Received: (qmail 21169 invoked by uid 22791); 5 Jul 2008 12:34:13 -0000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from www.church-of-our-saviour.ORG (HELO thunker.thunk.org) (69.25.196.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 05 Jul 2008 12:33:50 +0000 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KF6x8-0004yM-Pc; Sat, 05 Jul 2008 08:33:22 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1KF6x8-0004rn-1O; Sat, 05 Jul 2008 08:33:22 -0400 Date: Sat, 05 Jul 2008 12:34:00 -0000 From: Theodore Tso To: Peter Zijlstra Cc: Roland McGrath , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Bcc: tytso@mit.edu Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080705123321.GA2862@mit.edu> References: <20080630181959.GA7988@mit.edu> <20080630192533.GE21660@redhat.com> <20080630201031.GF7988@mit.edu> <20080630204219.GA6631@redhat.com> <20080701024140.GB28143@mit.edu> <20080701070746.C6DAD15420E@magilla.localdomain> <20080701101507.GB22717@mit.edu> <20080701200632.6790A1541F5@magilla.localdomain> <20080701231327.GA5829@mit.edu> <1215251049.6320.15.camel@lappy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1215251049.6320.15.camel@lappy.programming.kicks-ass.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false 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-q3/txt/msg00048.txt.bz2 On Sat, Jul 05, 2008 at 11:44:09AM +0200, Peter Zijlstra wrote: > On Tue, 2008-07-01 at 19:13 -0400, Theodore Tso wrote: > > .. snip Ted talking about how using Systemtap is a pain .. > > Well said. Until the point where using Systemtap is less work than > recompile and boot I'm not remotely interested in even looking at it. To be fair, Systemtap has gotten a lot better. About a week ago or so the latest version in its git tree actually passes the "download, configure, make" test on Ubuntu Hardy. Apparently previous to that you needed to know about the magic --enable-staticdw configure option, but its build system has been made much smarter now, which is good. Kernel compiles with symbols *do* take longer, since DWARF is just such a bloated method of storing debugging information, and so the files get much, much bigger. However, if you are worried about your root partition filling up due to bloaded modules taking up a huge amount of space, you can do this: "make INSTALL_MOD_STRIP=1 modules_install; make INSTALL_MOD_PATH=/usr/lib/debug modules_install". I have this partially automated with some patches to make-kpkg, on my Ubuntu system. (Available on request). The real issue is that there is a bunch of basic usability issues that aren't well documented, or better yet, automated. As a result, people hit these things, get frustrated, and then go back to printk. They're not going to file bugs in some bugzilla; they're not going to switch their distribution to Fedora; they're just going to move on to something more productive. The really wierd thing is that this might make sense if Systemtap were primarily targetted at system administrators, and not kernel developers. If this were so, making a bunch of installation issues distro-specific, and only worrying about distro-supplied kernels and not about kernel developer workflow might make sense. But given that a common excuse I've heard for the paucity of tapsets is "well, we need the kernel developer's expertise", and the fact that Systemtap has various UI decisions that really seem to make it much more optimized for developers (there are various things that in Dtrace can be done with a single command line, but which in Systemtap requires a much longer scripts, which is bad for system administrators who find it much easier to use DTrace as a result), this just seems to be a very puzzling gap. > Also, it would be really great if you could write probes in regular C, > some pseudo C language just messes up my mind. You can. Just surround the code with %{ and %} symbols. In fact, you have to do this a lot in tapsets. - Ted