From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16569 invoked by alias); 27 May 2007 01:44:21 -0000 Received: (qmail 16562 invoked by uid 22791); 27 May 2007 01:44:20 -0000 X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,BAYES_50,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,SARE_LWSHORTT,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; Sun, 27 May 2007 01:44:15 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l4R1i366022596 for ; Sat, 26 May 2007 21:44:03 -0400 Received: from gateway.sf.frob.com (vpn-14-88.rdu.redhat.com [10.11.14.88]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l4R1i2CA001622; Sat, 26 May 2007 21:44:03 -0400 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id E9259357B; Sat, 26 May 2007 18:44:01 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id BA55B1F8511; Sat, 26 May 2007 18:44:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Keniston X-Fcc: ~/Mail/utrace Cc: systemtap Subject: Re: updated uprobes patches In-Reply-To: Jim Keniston's message of Friday, 25 May 2007 16:28:49 -0700 <1180135729.6677.2.camel@ibm-ni9dztukfq8.beaverton.ibm.com> X-Shopping-List: (1) Ferocious chocolate directions (2) Ripe 'n' Sweet Promotion cheeses (3) Impatient loads Message-Id: <20070527014401.BA55B1F8511@magilla.localdomain> Date: Sun, 27 May 2007 01:44:00 -0000 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-q2/txt/msg00402.txt.bz2 I didn't catch up on the threads from Ernie's review until after Jim posted this new version. I have not reviewed the current code in great detail. Had I been active in the discussion a couple of weeks ago, I would have expressed by strong opposition to keeping the mm_struct change. I think it's essential that the code be turned into an independent module requiring no changes in the base kernel (unless they are changes to the formal utrace interfaces). From skimming the code, the mm_struct field seems to be the only thing preventing it now. This would also be a boon to developers immediately, since they could hack on the modules using e.g. their standard Fedora kernels already installed. I believe the value of being a clean module outweighs, in the short term for development, any performance concerns arising about overeager deallocation, insufficient sharing, etc. I'd say work with a modular version right away, sacrificing in the first cut whatever you have to sacrifice to make it work as a separate module. Then we'll get to further refinements like improving the sharing and reuse, along with plenty more refinements in other areas that are just as pressing. Thanks, Roland