From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12360 invoked by alias); 6 Jul 2008 15:47:47 -0000 Received: (qmail 12352 invoked by uid 22791); 6 Jul 2008 15:47:46 -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; Sun, 06 Jul 2008 15:47:23 +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 m66FlLHb029190; Sun, 6 Jul 2008 11:47:21 -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 m66FlL7p023747; Sun, 6 Jul 2008 11:47:21 -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 m66FkmXR007546; Sun, 6 Jul 2008 11:47:20 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id BA7778001FF; Sun, 6 Jul 2008 11:46:31 -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 m66FkF7h016172; Sun, 6 Jul 2008 11:46:15 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m66FkCEn016171; Sun, 6 Jul 2008 11:46:12 -0400 Date: Sun, 06 Jul 2008 15:47:00 -0000 From: "Frank Ch. Eigler" To: Christoph Hellwig Cc: ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080706154612.GL2881@redhat.com> References: <1214580213.3394.40.camel@localhost.localdomain> <20080627155018.GC14894@parisc-linux.org> <1214583502.7698.15.camel@weaponx> <20080627163056.GB1416@lst.de> <20080628072605.GA505@in.ibm.com> <20080629084002.GA24131@lst.de> <20080630051034.GA4970@in.ibm.com> <20080630112913.GA18817@lst.de> <20080630171246.GB21660@redhat.com> <20080706123414.GA9265@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080706123414.GA9265@lst.de> 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-q3/txt/msg00054.txt.bz2 Hi - On Sun, Jul 06, 2008 at 02:34:14PM +0200, Christoph Hellwig wrote: > > For systemtap's purposes, that is sufficient. Our probes are meant to > > run non-intrusively (they do not mess with user thread scheduling, > But that's not what matters. Really? Exactly what kinds/degrees of intrusiveness do you believe would be acceptable, and still be dtrace-level useful, and how did you come up with that list? > We don't add kernel interface for out of tree modules. That is a specific example of an attitude that I hope will be reexamined if y'all want to support dtrace-level introspection. > And thinking about it - having to compile out of tree kernel modules > on the fly to trace user space processes is just braindead. I gladly grant "counterintuitive", especially if one's intuition is limited to probing just one's own pet user-space process. It is a different matter when one needs to seamlessly probe a mixture of kernel activities, daemons, and user processes. > > > [...] For complex traces doing this in userspace is for sure a better idea. > > > > Can you elaborate upon this more complex scenario? > > For complex traces you basically want a ptrace without the signal mess. > See the utrace list for some design ideas. I'm well aware of the utrace list traffic, and that describes a low-level debugger interface API. You're not describing a "complex .. trace ... scenario" -- i.e., the purpose that you imagine ptrace-via-utrace is *the* appropriate solution for. - FChE