From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27063 invoked by alias); 16 Nov 2007 22:23:02 -0000 Received: (qmail 27056 invoked by uid 22791); 16 Nov 2007 22:23:01 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,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; Fri, 16 Nov 2007 22:22:59 +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.1) with ESMTP id lAGMMwKI010797; Fri, 16 Nov 2007 17:22:58 -0500 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 lAGMMw1L024150; Fri, 16 Nov 2007 17:22:58 -0500 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 lAGMMXfs031017; Fri, 16 Nov 2007 17:22:57 -0500 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 4AA548001FF; Fri, 16 Nov 2007 17:22:17 -0500 (EST) 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 lAGMM1P7014520; Fri, 16 Nov 2007 17:22:01 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id lAGMM0Bw014519; Fri, 16 Nov 2007 17:22:00 -0500 Date: Fri, 16 Nov 2007 22:23:00 -0000 From: "Frank Ch. Eigler" To: Jim Keniston Cc: systemtap@sourceware.org Subject: Re: user instruction tracing patch? Message-ID: <20071116222200.GF25326@redhat.com> References: <20071115035803.GE32440@redhat.com> <1195175032.3804.163.camel@dyn9047018096.beaverton.ibm.com> <1195241772.3965.42.camel@dyn9047018096.beaverton.ibm.com> <20071116192034.GA25326@redhat.com> <1195248052.3965.66.camel@dyn9047018096.beaverton.ibm.com> <20071116203708.GC25326@redhat.com> <1195247268.8520.4.camel@dyn9047018096.beaverton.ibm.com> <20071116212420.GE25326@redhat.com> <1195249801.8520.13.camel@dyn9047018096.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1195249801.8520.13.camel@dyn9047018096.beaverton.ibm.com> User-Agent: Mutt/1.4.1i 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: 2007-q4/txt/msg00365.txt.bz2 Hi - > > [...] > > probe program("/bin/vi").function("malloc") { } > > > > would be a request to probe all running (and forseeably, any future) > > copies of vi. To filter further, I imagine additional qualifiers such > > as ".pid(NUM)", ".uid(NUM)". These are all to identify the potential > > probing target processes. > > In the above examples, if NUM could be a variable name, then I think > we're in business... especially if it could be a set of pids or uids > [...] Well, it depends how variable that data is. Another way to think about it is to think of the probe point type of specification as "additive", and as conditionals as "subtractive". If the data is fixed at/near startup time, then we can "add" probes only to the targeted processes and not bother any of the others. If the data is highly variable, it may be more appropriate to designate probes in them all, and "subtract" out the uninteresting ones on the fly by means of dynamic disabling conditions. - FChE