From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31566 invoked by alias); 6 Jul 2007 12:46:32 -0000 Received: (qmail 31557 invoked by uid 22791); 6 Jul 2007 12:46:31 -0000 X-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jul 2007 12:46:25 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l66CkKL4001640 for ; Fri, 6 Jul 2007 08:46:20 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l66CkKEr268596 for ; Fri, 6 Jul 2007 06:46:20 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l66CkKRa020010 for ; Fri, 6 Jul 2007 06:46:20 -0600 Received: from hoji (wecm-9-67-141-10.wecm.ibm.com [9.67.141.10]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l66CkJpW019988; Fri, 6 Jul 2007 06:46:19 -0600 Received: by hoji (Postfix, from userid 1000) id 5BCB56022E; Fri, 6 Jul 2007 08:46:19 -0400 (EDT) Date: Fri, 06 Jul 2007 12:46:00 -0000 To: "Frank Ch. Eigler" Cc: dcnltc@linux.vnet.ibm.com, systemtap@sourceware.org Subject: Re: proposed instruction trace support in SystemTap Message-ID: <20070706124619.GB22827@us.ibm.com> Mail-Followup-To: "Frank Ch. Eigler" , dcnltc@linux.vnet.ibm.com, systemtap@sourceware.org References: <4689826A.9040902@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: grundym@us.ibm.com (grundy) 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: 2007-q3/txt/msg00026.txt.bz2 On Thu, Jul 05, 2007 at 03:37:02PM -0400, Frank Ch. Eigler wrote: > Particularly, to turn the probe on and off by explicit function calls. > > Regarding semantics, this is tricky business. Turning off active > probes is relatively simple, because even if the underlying probe API > doesn't support instantaneous (atomic) disarming, we can simulate it > until the API catches up (by adding an "am I supposed to be disarmed?" > conditional to the handler). Turning them *on* is different - we > can't help but possibly miss a couple of events as the API catches up. Maybe we could support two levels of disarmed? One would be probepoints removed as discussed, the other could be probe points in, complete handler not firing (just enough to say "we're not active" and return). In tapscripts what I will do sometimes is have an active variable that gets checked at the beginning of every handler. When the trigger is hit to start recording, the variable is changed and recording begins. It would be good to have a way to be sure that when you activate a set of probes, that they are actually active and not on the way to being active. Thanks Mike