From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2567 invoked by alias); 2 Jul 2008 19:27:12 -0000 Received: (qmail 2549 invoked by uid 22791); 2 Jul 2008 19:27:10 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_34,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jul 2008 19:26:40 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m62JQcs0012726 for ; Wed, 2 Jul 2008 15:26:38 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m62JQa1c010534; Wed, 2 Jul 2008 15:26:37 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.yyz.redhat.com [10.15.16.9]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m62JPtq0010593; Wed, 2 Jul 2008 15:26:28 -0400 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id C50C28001FF; Wed, 2 Jul 2008 15:25:38 -0400 (EDT) Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id m62JPMIZ002755; Wed, 2 Jul 2008 15:25:22 -0400 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id m62JPJaf002754; Wed, 2 Jul 2008 15:25:19 -0400 Date: Wed, 02 Jul 2008 19:27:00 -0000 From: "Frank Ch. Eigler" To: Theodore Tso Cc: Roland McGrath , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080702192519.GA31206@redhat.com> References: <20080630010423.GA7068@redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080701231327.GA5829@mit.edu> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00015.txt.bz2 Hi - On Tue, Jul 01, 2008 at 07:13:27PM -0400, Theodore Tso wrote: > [...] And one of the major flaws of the Linux's RAS tools is that > the LKML development community doesn't use them; and to the extent > that tapsets would be written more quickly if they are easy for > kernel developers who aren't depending on distro packaging and > distro building of systemtap. [...] Please excuse my return to this point, but it meshes with something else: > probe kernel.function ("vfs_write"), > kernel.function ("vfs_read") > { > dev_nr = $file->f_dentry->d_inode->i_sb->s_dev > inode_nr = $file->f_dentry->d_inode->i_ino > > if (dev_nr == ($1 << 20 | $2) # major/minor device > && inode_nr == $3) > printf ("%s(%d) %s 0x%x/%u\n", > execname(), pid(), probefunc(), dev_nr, inode_nr) > } 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 } Then this definition would be shipped with the kernel or systemtap, tested in one or the other build system for currency. (Not by coincidence, something much like that is already in our tapset, just lacks those two values.) Then the end user just does probe vfs.read { if (dev_nr != MKDEV(2,3)) printf ("whatever you want to print") } **** or **** Kernel maintainers could add a marker or two right into their C code: vfs_read() { /* ... */ trace_mark (vfs_read, "dev %u inode %u whatever %s", expression1, expression2, whatever); /* ... */ } And that's it. It's compiled-in, and checked as a part of your routine builds. Then the systemtap-side interpration code is trivial, and anyone can write it. And it doesn't require debugging data. probe vfs.read = kernel.mark("vfs_read") { dev_nr = $arg1; inode_nr = $arg2 } probe vfs.read = kernel.mark("vfs_read") { dev_nr = $arg1; inode_nr = $arg2 } If people could get over the funny look of the markers (since performance effects have been shown to be negligible), they could make a significant contribution to this problem, with just a few lines of C code. - FChE