From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15634 invoked by alias); 7 Jul 2008 05:59:56 -0000 Received: (qmail 15625 invoked by uid 22791); 7 Jul 2008 05:59:55 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay.2ka.mipt.ru (HELO 2ka.mipt.ru) (194.85.80.65) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 05:59:29 +0000 Received: from 2ka.mipt.ru (localhost [127.0.0.1]) by 2ka.mipt.ru (8.14.1/8.14.1) with ESMTP id m675vrPc006044; Mon, 7 Jul 2008 09:57:53 +0400 Received: (from johnpol@localhost) by 2ka.mipt.ru (8.14.1/8.12.1/Submit) id m675vrgN006031; Mon, 7 Jul 2008 09:57:53 +0400 Date: Mon, 07 Jul 2008 05:59:00 -0000 From: Evgeniy Polyakov To: "Frank Ch. Eigler" Cc: Christoph Hellwig , systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080707055753.GB26263@2ka.mipt.ru> References: <20080629084002.GA24131@lst.de> <20080630051034.GA4970@in.ibm.com> <20080630112913.GA18817@lst.de> <20080630171246.GB21660@redhat.com> <20080706123414.GA9265@lst.de> <20080706154612.GL2881@redhat.com> <20080706163533.GA16721@2ka.mipt.ru> <20080706182307.GA29895@2ka.mipt.ru> <20080706213920.GA1936@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080706213920.GA1936@redhat.com> User-Agent: Mutt/1.5.9i 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/msg00062.txt.bz2 Hi Frank. On Sun, Jul 06, 2008 at 05:39:20PM -0400, Frank Ch. Eigler (fche@redhat.com) wrote: > > Unexporting some things allows to change them in order to fix some bugs, > > create better abstraction, introduce new feature... Having all calls > > forever does not provide any gain to the kernel, instead project can be > > pushed into the kernel, so anyone would win. > > OK, so you think systemtap should go into the kernel ... Getting history of systemtap, I'm not sure it will be easily possible :) But it is good project for overall Linux advertisement. Personally I will not use it, since it is simpler (and very likely has smaller performance overhead) to put various kinds of counters all over needed places to get required statistics for hot pathes like VM and put debug prints in the slow parts. > > Hmmm... Utrace suddenly stopped to work? > > (I assume you know that utrace is a kernel-side API. You may realize > is that we are using it (via another layered module uprobes) to place > probes into user-space programs.) And adds additional layer. > > Even ptrace will work in described cases, if requested data is > > accessible from userspace. [...] > > ... but now systemtap stay out to userspace? I don't understand. You asked how to get needed information. It can be accessed via ptrace, so there is no need to have additional kernel module to get it. > > And is it really much simpler to use dtrace scripts [...] for that? > > Simpler than what? A userspace debugger that messes with thread state? Yes, ptrace approach is a bit messy, still there is utrace, and now additional systap layer. > > (btw, does systemtap has the same complexity of script writing? > > If you point out an example of what you consider a complex dtrace > script, I can try to answer that. Things like syscall::*read:entry, syscall::*write:entry this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0; I.e. 'this' and 'self' pointer -- Evgeniy Polyakov