From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27936 invoked by alias); 1 Jul 2008 01:21:02 -0000 Received: (qmail 27927 invoked by uid 22791); 1 Jul 2008 01:21:01 -0000 X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e1.ny.us.ibm.com (HELO e1.ny.us.ibm.com) (32.97.182.141) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 Jul 2008 01:20:38 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m611KaFY026817 for ; Mon, 30 Jun 2008 21:20:36 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m611KaLh231180 for ; Mon, 30 Jun 2008 21:20:36 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m611KZ9Y006114 for ; Mon, 30 Jun 2008 21:20:35 -0400 Received: from [9.47.18.139] (dyn9047018139.beaverton.ibm.com [9.47.18.139]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m611KYUt006089; Mon, 30 Jun 2008 21:20:34 -0400 Subject: Re: [Ksummit-2008-discuss] DTrace From: Jim Keniston To: "Frank Ch. Eigler" Cc: Christoph Hellwig , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com, utrace-devel@redhat.com In-Reply-To: <20080630171246.GB21660@redhat.com> References: <20080627150424.GB14894@parisc-linux.org> <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> Content-Type: text/plain Date: Tue, 01 Jul 2008 01:21:00 -0000 Message-Id: <1214874950.3949.47.camel@dyn9047018139.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00000.txt.bz2 On Mon, 2008-06-30 at 13:12 -0400, Frank Ch. Eigler wrote: > Hi - > > On Mon, Jun 30, 2008 at 01:29:13PM +0200, Christoph Hellwig wrote: > > > [...] This might be getting a little offtopic for the kernel summit > > discuss list, but let's start anyway, we can move this to a better > > suited list, although I can't think of one except for linux-kernel. > > systemtap@sources.redhat.com > utrace-devel@redhat.com > > > > I'm not sure if that's the current design, but I can't find any > > evidence in the code that it allows running handlers in process > > context, all that's available is a kernel callback. [...] To clarify, it's a kernel callback that runs in the context of the probed thread -- like other utrace-based callbacks. And like other utrace-based callbacks, a uprobes handler can block for stuff like copy_to/from_user()... although I believe systemtap will support only non-blocking handlers for now. > > For systemtap's purposes, that is sufficient. Our probes are meant to > run non-intrusively (they do not mess with user thread scheduling, > their VM state, strictly limited time & space consumption), so > actually injecting equivalent snippets of code into userspace for > execution there does not seem to buy anything. Plus, like dtrace, we > want scripts to be able to intermix probes (=> share data) amongst > kernel and multiple user-space threads, and this seems most naturally > done by running the probes themselves in kernel space. Yes. > > > > [...] What we really need is a userspace interface so that it > > actually can be used by thing like frysk or an implementation of the > > userspace dtrace hooks. Userspace dtrace hooks could be probed using systemtap-generated uprobes, whether or not the hooks all funnel into the same user-space handler function. > > That will get built as other tools require it. Systemtap per se will > likely not. Two years back, we explored the possibility of systemtap translating a script into an ad hoc tracer app that used ptrace. The idea was that that would suffice in cases where the user doesn't care to see what's going on in the kernel. My experience was that ptrace wasn't up to the task. Perhaps when we nail down the right utrace-based, ptrace-replacement system call interface (utracer II, or whatever -- see the current discussion on the utrace-devel list), we should revisit that option. It would make systemtap accessible to the ordinary application programmer, without him/her needing root or stapdev to bless his/her script. Stuff that's in uprobes (e.g., kprobes-style single-stepping out of line, to allow real-time tracing of multithreaded apps) can be made available to the new syscall API and/or utrace. > > > > [...] For complex traces doing this in userspace is for sure a better idea. > > Can you elaborate upon this more complex scenario? > > > - FChE Jim Keniston