From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7025 invoked by alias); 6 Jul 2008 18:24:08 -0000 Received: (qmail 6916 invoked by uid 22791); 6 Jul 2008 18:24:06 -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; Sun, 06 Jul 2008 18:23:49 +0000 Received: from 2ka.mipt.ru (localhost [127.0.0.1]) by 2ka.mipt.ru (8.14.1/8.14.1) with ESMTP id m66IN9UM006137; Sun, 6 Jul 2008 22:23:09 +0400 Received: (from johnpol@localhost) by 2ka.mipt.ru (8.14.1/8.12.1/Submit) id m66IN8NT006136; Sun, 6 Jul 2008 22:23:08 +0400 Date: Sun, 06 Jul 2008 18:24:00 -0000 From: Evgeniy Polyakov To: "Frank Ch. Eigler" Cc: Christoph Hellwig , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080706182307.GA29895@2ka.mipt.ru> References: <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> <20080706154612.GL2881@redhat.com> <20080706163533.GA16721@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00057.txt.bz2 On Sun, Jul 06, 2008 at 02:00:03PM -0400, Frank Ch. Eigler (fche@redhat.com) wrote: > >> That is a specific example of an attitude that I hope will be > >> reexamined if y'all want to support dtrace-level introspection. > > > > I believe the only answer you will get is 'no'. Both for dtrace-like > > stuff and ability to add unmaintained interfaces into the kernel. > > > > Out-of-tree stuff can appear and disappear, change its internal > > structures, API, ABI [...] > > Yes, well, it turns out that the number of systemtap-specific kernel > interfaces we have requested is ... precisely ... zero. Well, in the mail you replied to there was objection to add new interfaces. > We have on occasion asked that some established module interfaces > simply not be *unexported*, but almost all of those requests have been > turned down, requiring us to kludge. We have helped promote a > systemtap-neutral instrumentation mechanism (markers), along with a > project with a near-decade history of stable instrumentation (ltt/ng), > and one can see the progress (?) that this has made even since Karim's > "emperor is naked" note two (!) years ago. 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. > >> > 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. > > > > Out of curiosity, how in the hell administrator or any other non kernel > > hacker person needs to have ability to tap into userspace process via > > kernel module? > > Think about how a non-intrusive system-wide probing must work, if it > is desirable not to interfere with e.g. thread scheduling or VM state. > Specifically, if we don't want to context-switch from threads (thereby > interfering with contention effects we may want to measure), nor page > data in/out just to satisfy probe data (thereby generating more I/O > and associated distortions). It seems only kernel-side code can do > all of that. Do you have a better suggestion? Hmmm... Utrace suddenly stopped to work? Even ptrace will work in described cases, if requested data is accessible from userspace. Not sure about VM states, but kernel hides this data on purpose, if it does need to be viewed from userspace, you can extend statistics. And is it really much simpler to use dtrace scripts (btw, does systemtap has the same complexity of script writing?) for that? -- Evgeniy Polyakov