From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27621 invoked by alias); 7 Oct 2009 19:51:17 -0000 Received: (qmail 27589 invoked by uid 22791); 7 Oct 2009 19:51:14 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,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; Wed, 07 Oct 2009 19:51:10 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n97Jp8LT032628 for ; Wed, 7 Oct 2009 15:51:08 -0400 Received: from fche.csb (vpn-240-19.phx2.redhat.com [10.3.240.19]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n97Jp8p6032254; Wed, 7 Oct 2009 15:51:08 -0400 Received: by fche.csb (Postfix, from userid 2569) id D96345847D; Wed, 7 Oct 2009 15:51:07 -0400 (EDT) To: Rajasekhar Duddu Cc: systemtap@sources.redhat.com Subject: Re: [PATCH v3] Tracepoint Tapset for Memory Subsystem References: <20090919050102.GA3767@rajduddu> <4AB90BE0.4030405@redhat.com> <4AB94A1B.4090801@redhat.com> <20090924180817.GA9698@rajduddu> <4ABD3B2B.4020107@redhat.com> <20090930101156.GA3792@rajduddu> <20091002151344.GA9516@rajduddu> <20091007130728.GA6574@rajduddu> From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 07 Oct 2009 19:51:00 -0000 In-Reply-To: <20091007130728.GA6574@rajduddu> (Rajasekhar Duddu's message of "Wed, 7 Oct 2009 18:37:28 +0530") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00084.txt.bz2 Rajasekhar Duddu writes: > [...] >> Nice. I thought that the raison d'etre for these aliases was to >> abstract the presence or absence of tracepoints, so is there no >> fallback kprobe available? Something like this: >> > Fallback kprobe is not available for other memory functions because > the variables exported by them are will be modified. Could you elaborate? Do you mean that the same values may not be available from a kprobe context? - FChE