From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11292 invoked by alias); 2 Jul 2008 21:40:22 -0000 Received: (qmail 11282 invoked by uid 22791); 2 Jul 2008 21:40:20 -0000 X-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34,SPF_HELO_PASS,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from www.church-of-our-saviour.org (HELO thunker.thunk.org) (69.25.196.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jul 2008 21:40:03 +0000 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KEA39-0007Y6-AS; Wed, 02 Jul 2008 17:39:39 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1KEA38-00068w-O4; Wed, 02 Jul 2008 17:39:38 -0400 Date: Wed, 02 Jul 2008 21:40:00 -0000 From: Theodore Tso To: "Frank Ch. Eigler" Cc: Roland McGrath , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Bcc: tytso@mit.edu Subject: Potential Systemtap topics for the Kernel Summit Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080702192519.GA31206@redhat.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false 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/msg00022.txt.bz2 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); > /* ... */ > } So it sounds like potential Systemtap topics for the kernel summit might include: A) Enhancements to kbuild to better support kernel developers who want to use systemtap. B) Discussion of list of tapsets and markers that would be useful for System administrators wanting to use systemtap. This is one place where if someone could volunteer to examine some of the Dtrace examples and blog entries where Dtrace users have raved about how Dtrace saved their bacon by instantly identifying some performance problem, and then assemble a "tapset or marker WANTED" bounty list, that would be very useful. One potential problem is that I suspect kernel developers may not know or have the intuition of what sort of markers or tapsets would be most useful. Having a targetted wish list would be very useful. (We might then have some discussions about whether a particular tapset or marker is too hard to maintain, or represents too much of a performance hit, but at least would be dealing with concrete requests.) C) Whether tapsets/markers should be maintained inside the kernel, and if so, how. D) What is the right way to do user probes. Of course, if some of these topics are handled via e-mail before the kernel summit, even better. But somehow, I'm guessing there will still be more to talk about. :-) The bottom line is more communication between the kernel and systemtap developers is a good thing (and getting more kernel developers to use systemtap would be a good start). And I do want to make sure I get across that I wasn't trying to imply that all of the work and changes should happen on the systemtap side. In fact, if you look at some of the topics that have come up on this thread, more than few of them involve changes in the kernel side.... Does this sound reasonable? - Ted