From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18563 invoked by alias); 7 Jul 2008 17:44:45 -0000 Received: (qmail 18550 invoked by uid 22791); 7 Jul 2008 17:44:44 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from E23SMTP06.au.ibm.com (HELO e23smtp06.au.ibm.com) (202.81.18.175) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 07 Jul 2008 17:44:23 +0000 Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [202.81.18.225]) by e23smtp06.au.ibm.com (8.13.1/8.13.1) with ESMTP id m67HhiI5030341 for ; Tue, 8 Jul 2008 03:43:44 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by sd0109e.au.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m67HiIj3284122 for ; Tue, 8 Jul 2008 03:44:19 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m67HiHmD014154 for ; Tue, 8 Jul 2008 03:44:18 +1000 Received: from in.ibm.com ([9.77.123.137]) by d23av02.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m67Hi99A014045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jul 2008 03:44:14 +1000 Date: Mon, 07 Jul 2008 17:44:00 -0000 From: "K.Prasad" To: Christoph Hellwig Cc: Peter Zijlstra , Theodore Tso , ksummit-2008-discuss@lists.linux-foundation.org, Roland McGrath , systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080707174400.GA17445@in.ibm.com> Reply-To: prasad@linux.vnet.ibm.com References: <20080630204219.GA6631@redhat.com> <20080701024140.GB28143@mit.edu> <20080701070746.C6DAD15420E@magilla.localdomain> <20080701101507.GB22717@mit.edu> <20080701200632.6790A1541F5@magilla.localdomain> <20080701231327.GA5829@mit.edu> <1215251049.6320.15.camel@lappy.programming.kicks-ass.net> <20080705100536.GA18534@lst.de> <20080705180432.GA6077@in.ibm.com> <20080706123647.GB9265@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080706123647.GB9265@lst.de> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00069.txt.bz2 On Sun, Jul 06, 2008 at 02:36:47PM +0200, Christoph Hellwig wrote: > On Sat, Jul 05, 2008 at 11:34:32PM +0530, K.Prasad wrote: > > > You can write probes in plain C, in fact I do this all the time. what's > > > missing is a nice and easy to use channel to get the traces to userspace > > > and interpret them, and helper for poking at kernel data structures. > > > > > As you might be aware the "trace" interface which is part of the -mm > > tree was meant to satisfy such needs. > > From the interface POV it's a step in the right direction. But to make > adhoc kprobe tracing viable for anyone but hardcore kernel hackers we > basically want a /debug/trace always availble so that the traces just > need to relay_printk() on it. The relay_printk() creates a directory structure that contains control and data files under the 'debugfs' mounted path, while the user is kept oblivious of the internals that are required to set it up. The user simply does a relay_printk(relay_structure, "my desired string") and the output is sent to the data file(s). > We also want some helpers to encode > complex strucures. See the current printk on steroids discussion on > lkml which would be pretty helpful for it. On a related note, one of the improvements envisaged for the "relay_printk()" interface was the ability to have user-defined callback functions - which would be invoked before the "trace" infrastructure actually accesses the data for output. Typical uses for the same, could range from defining call-backs for obtaining/releasing locks on each protected variable without the user having to bother about the same ... or to prefix/append a given data with user-defined string automatically through the callback function everytime before being output. Such callback functions may also be used to encode/decode data into/from complex data structures before they are sent to user-space without the need to explicitly program them before every *printk(). Say something like - also print i_ino when printing i_count etc. Not sure if the example represents your case of a need for "helpers to encode complex structures". Thanks, K.Prasad