From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7582 invoked by alias); 6 Jul 2008 16:36:33 -0000 Received: (qmail 7575 invoked by uid 22791); 6 Jul 2008 16:36:33 -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 16:36:15 +0000 Received: from 2ka.mipt.ru (localhost [127.0.0.1]) by 2ka.mipt.ru (8.14.1/8.14.1) with ESMTP id m66GZZum027005; Sun, 6 Jul 2008 20:35:35 +0400 Received: (from johnpol@localhost) by 2ka.mipt.ru (8.14.1/8.12.1/Submit) id m66GZY7X026992; Sun, 6 Jul 2008 20:35:34 +0400 Date: Sun, 06 Jul 2008 16:36: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: <20080706163533.GA16721@2ka.mipt.ru> References: <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> <20080706154612.GL2881@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080706154612.GL2881@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/msg00055.txt.bz2 Hi Frank. On Sun, Jul 06, 2008 at 11:46:12AM -0400, Frank Ch. Eigler (fche@redhat.com) wrote: > > 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. 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 and degree of fevered consciousness delirium, but kernel interface has to be supported long and long time after it was added, so there is no way to add some interface without its users being in kernel. > > 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? -- Evgeniy Polyakov