From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22940 invoked by alias); 27 Jun 2006 20:01:34 -0000 Received: (qmail 22930 invoked by uid 22791); 27 Jun 2006 20:01:33 -0000 X-Spam-Status: No, hits=-3.6 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) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Jun 2006 20:01:30 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5RK1Sa1008512 for ; Tue, 27 Jun 2006 16:01:28 -0400 Received: from pobox.hsv.redhat.com (pobox.hsv.redhat.com [172.16.16.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5RK1QuX018096; Tue, 27 Jun 2006 16:01:27 -0400 Received: from dhcp-2.hsv.redhat.com (dhcp-2.hsv.redhat.com [172.16.17.2]) by pobox.hsv.redhat.com (8.12.8/8.12.8) with ESMTP id k5RK1NsL027879; Tue, 27 Jun 2006 16:01:24 -0400 Subject: RE: pre-compiled modules From: David Smith To: "Stone, Joshua I" Cc: "Frank Ch. Eigler" , Systemtap List In-Reply-To: References: Content-Type: text/plain Date: Tue, 27 Jun 2006 22:08:00 -0000 Message-Id: <1151438368.24128.31.camel@dhcp-2.hsv.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00704.txt.bz2 Thanks for the response. See stuff below. On Tue, 2006-06-27 at 12:47 -0700, Stone, Joshua I wrote: > On Tuesday, June 27, 2006 11:52 AM, David Smith wrote: > >> Blatant modversions mismatches will be detected during the actual > >> insertion attempt - IMO there is no need to make a dry run first. We > >> will need more self-protective code though for purposes of verifying > >> module addresses. Specifically, we need to find a kernel API routine > >> that, given a module name, gives its loaded base address. > > > > Hmm, I hadn't considered that. Will this code go in the module itself > > or go in the runtime? > > Is there a difference? The runtime is still compiled into the module, > right? Sorry, I meant to say: "Will this code go in the module itself or the stpd daemon?" > > To help move this along a bit, I've attached a patch that modifies the > > systemtap front end to take 2 new options: > > > > -S Save the compiled module in the current directory > > I would prefer to see an option to specify the directory, instead of > assuming $PWD. You could always use '-S .', but some people might want > to drop it somewhere else. Another possibility instead of -S is to just > extend the -m option to allow a path. That's easy enough to add, but it seems like that 99% of the time I'd want it to go in the current directory. Anyone else got any opinions? > > -P PRE_COMPILED_MODULE > > Run pre-compiled module > > Looks fine. > > Have you thought about concurrent access to a precompiled module? If > you have a systemtap module foo.ko on a multi-user system, you might end > up with a situation where multiple people want to run it at the same > time. Of course you can only insmod one at a time, if nothing else > because of the naming issue. Hmm, no I hadn't considered that. We've also got a similar but different problem. What happens when 2 users both compile two different scripts called 'foo.stp' into 'foo.ko', then try to run them concurrently? I'm unsure of what we can do in either case. -- David Smith dsmith@redhat.com Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)