From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4494 invoked by alias); 8 Jul 2008 23:32:17 -0000 Received: (qmail 4485 invoked by uid 22791); 8 Jul 2008 23:32:16 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from out02.mta.xmission.com (HELO out02.mta.xmission.com) (166.70.13.232) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Jul 2008 23:31:55 +0000 Received: from [166.70.13.201] (helo=mgr1.xmission.com) by out02.mta.xmission.com with esmtp (Exim 4.62) (envelope-from ) id 1KGMfN-0007DV-2H; Tue, 08 Jul 2008 17:32:13 -0600 Received: from c-24-130-11-59.hsd1.ca.comcast.net ([24.130.11.59] helo=frodo.ebiederm.org) by mgr1.xmission.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1KGMf2-0000Sm-5c; Tue, 08 Jul 2008 17:31:53 -0600 Received: from frodo.ebiederm.org (localhost [127.0.0.1]) by frodo.ebiederm.org (8.14.1/8.14.1/Debian-9) with ESMTP id m68NNqAf025281; Tue, 8 Jul 2008 16:23:52 -0700 Received: (from eric@localhost) by frodo.ebiederm.org (8.14.1/8.14.1/Submit) id m68NNqNU025280; Tue, 8 Jul 2008 16:23:52 -0700 X-Authentication-Warning: frodo.ebiederm.org: eric set sender to ebiederm@xmission.com using -f From: ebiederm@xmission.com (Eric W. Biederman) To: James Bottomley Cc: "Frank Ch. Eigler" , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com References: <20080630010423.GA7068@redhat.com> <1214853732.3381.35.camel@localhost.localdomain> Date: Tue, 08 Jul 2008 23:32:00 -0000 In-Reply-To: <1214853732.3381.35.camel@localhost.localdomain> (James Bottomley's message of "Mon, 30 Jun 2008 14:22:12 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Received-SPF: neutral (mgr1.xmission.com: 24.130.11.59 is neither permitted nor denied by domain of xmission.com) client-ip=24.130.11.59; envelope-from=ebiederm@xmission.com; helo=frodo.ebiederm.org; X-SA-Exim-Connect-IP: 24.130.11.59 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on sa01.xmission.com X-Spam-Level: X-Spam-Combo: ;James Bottomley X-Spam-Relay-Country: X-Spam-Report: * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -0.7 BAYES_20 BODY: Bayesian spam probability is 5 to 20% * [score: 0.0616] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 XM_SPF_Neutral SPF-Neutral Subject: Re: [Ksummit-2008-discuss] DTrace X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on mgr1.xmission.com) 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/msg00099.txt.bz2 James Bottomley writes: > I've also found it very easy to crash the system under probe if you use > the wrong build tree for the running kernel (not a problem, I know that > enterprise customers run into, but a common one for kernel developers). > Since we have a kernel build version that increments with every build, > it would be useful to sanity check the one systemtap pulled out of the > debug with the one in the running kernel. Interesting. I wonder how much the DTrace in kernel interpreter protects them from that. >> * dtrace "just works" >> >> Yeah, so I hear, but think about how different their target >> environment is. Their kernel hardly changes (several fixed APIs, >> ABIs): this has huge implications. Their kernel was willing to >> insert probes (~ markers), a bunch of build system changes (debug >> info subset transcribing). Here in linux land, we suffer >> multifaceted tensions and it is hard to go toward a goal without >> obstructions (well-meaning as they may be). > > The goal has to be well articulated and agreed to. Open source is rapid > at progressing towards common goals ... it's when the goals aren't > common that progress gets bogged down. In addition to a well articulated goal. A feature poor implementation that works and gives people lots of itches to scratch helps. What is the goal with SystemTap? The goal with Dtrace (and I am badly paraphrasing) is to allow a system level look into what is happening. There was a talk at OLS in 2006 entitled "Why user space sucks." Which pointed out all of the silly things that were happening during boot from a system level perspective. How do we make that kind of tracing easy with SystemTap? Those are the interesting questions, and in general they shouldn't need complicated tapsets and other prebuilt knowledge. It is the global view of how things are connected that looks most interesting. Eric