From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-9291-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 9463 invoked by alias); 2 Jul 2008 22:54:30 -0000
Received: (qmail 9454 invoked by uid 22791); 2 Jul 2008 22:54:30 -0000
X-Spam-Status: No, hits=-2.0 required=5.0 	tests=BAYES_00,J_CHICKENPOX_34
X-Spam-Check-By: sourceware.org
Received: from mail.vyatta.com (HELO mail.vyatta.com) (216.93.170.194)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jul 2008 22:54:07 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) 	by mail.vyatta.com (Postfix) with ESMTP id 9A2784F433E; 	Wed,  2 Jul 2008 15:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Score: -2.104
X-Spam-Level:
Received: from mail.vyatta.com ([127.0.0.1]) 	by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024) 	with ESMTP id RmXT0BhoLZl5; Wed,  2 Jul 2008 15:53:59 -0700 (PDT)
Received: from extreme (pool-71-245-98-107.ptldor.fios.verizon.net [71.245.98.107]) 	by mail.vyatta.com (Postfix) with ESMTP id DAEA24F4209; 	Wed,  2 Jul 2008 15:53:58 -0700 (PDT)
Date: Wed, 02 Jul 2008 22:54:00 -0000
From: Stephen Hemminger <shemminger@vyatta.com>
To: Theodore Tso <tytso@mit.edu>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,  ksummit-2008-discuss@lists.linux-foundation.org, Roland McGrath  <roland@redhat.com>, systemtap@sources.redhat.com
Subject: Re: [Ksummit-2008-discuss] Potential Systemtap topics for the  Kernel Summit
Message-ID: <20080702155357.6e258347@extreme>
In-Reply-To: <20080702213938.GA23574@mit.edu>
References: <20080630181959.GA7988@mit.edu> 	<20080630192533.GE21660@redhat.com> 	<20080630201031.GF7988@mit.edu> 	<20080630204219.GA6631@redhat.com> 	<20080701024140.GB28143@mit.edu> 	<20080701070746.C6DAD15420E@magilla.localdomain> 	<20080701101507.GB22717@mit.edu> 	<20080701200632.6790A1541F5@magilla.localdomain> 	<20080701231327.GA5829@mit.edu> 	<20080702192519.GA31206@redhat.com> 	<20080702213938.GA23574@mit.edu>
Organization: Vyatta
X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap.sourceware.org>
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
X-SW-Source: 2008-q3/txt/msg00026.txt.bz2

On Wed, 2 Jul 2008 17:39:38 -0400
Theodore Tso <tytso@mit.edu> wrote:

> On Wed, Jul 02, 2008 at 03:25:19PM -0400, Frank Ch. Eigler wrote:
> > So, one way a kernel developer could help write a tapset piece for us
> > is to encapsulate this into a tapset script fragment:
> > 
> > probe vfs.read = kernel.function ("vfs_read")
> >   {
> >     dev_nr = $...expression
> >     inode_nr = $...expression
> >   }
> > 
> > ****  or  ****
> > 
> > Kernel maintainers could add a marker or two right into their C code:
> > 
> > {
> >     /* ... */
> >     trace_mark (vfs_read, "dev %u inode %u whatever %s",
> >                           expression1, expression2, whatever);
> >     /* ... */
> > }

On a related topic. Why not figure out a way to embed the tapsets
into the kernel source (a.l.a Docbook)? If the tapsets are maintained in
a far-far away repository or even in a separate directory, then kernel
developers are sure to break tapsets all the time. But if the tapset
is "in your face" when dealing with code, then there is a chance of
keeping both up to date.