From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22653 invoked by alias); 29 Oct 2009 23:14:25 -0000 Received: (qmail 22645 invoked by uid 22791); 29 Oct 2009 23:14:24 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_SUB_OBFU_Q0,SARE_SUB_OBFU_Q1,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Oct 2009 23:14:17 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n9TNEF8j008532; Thu, 29 Oct 2009 19:14:15 -0400 Received: from [10.3.242.115] (vpn-242-115.phx2.redhat.com [10.3.242.115]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n9TNEETK032313; Thu, 29 Oct 2009 19:14:14 -0400 Message-ID: <4AEA21C6.8000303@redhat.com> Date: Thu, 29 Oct 2009 23:14:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Prerna Saxena CC: systemtap@sourceware.org, David Smith Subject: Re: Tapset for probing IRQs, workqueues, etc References: <4AE1E981.9050002@linux.vnet.ibm.com> <4AE602B6.7080809@redhat.com> <4AE9BAFB.70800@linux.vnet.ibm.com> In-Reply-To: <4AE9BAFB.70800@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2009-q4/txt/msg00366.txt.bz2 On 10/29/2009 08:55 AM, Prerna Saxena wrote: > Hi , > Posting a new version of the IRQ tapset. > > On 10/27/2009 01:42 AM, David Smith wrote: > >> >> I took a short look at your tapset. In general, it looks fine. >> >> I do have one question. You added a function called '_irqflags_str' to >> aux_syscalls.stp, but I couldn't find a caller of that new function in >> your tapset. It looks like you might have meant to call it for the >> 'flags' variables in irq_handler.entry and irq_handler.exit. > > I have not included the flags string on purpose for this probe point, > cos I think that one might need to look up the flags in specific > debugging scenarios only. It would not be required in most commonly used > cases, such as the attached example. However, I have documented the > function both inline in the tapset documentation and also in the man > pages, so that a script developer wanting to display a formatted string > can call the function when needed. It wouldn't hurt to have the tapset provide it as something like flags_str. That makes it more obvious for the user, and our optimizer should remove it automatically if it's not used. Josh