From owner-freebsd-current@FreeBSD.ORG Mon May 26 02:16:44 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 387C437B401; Mon, 26 May 2003 02:16:44 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8822043F3F; Mon, 26 May 2003 02:16:43 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc19i.dialup.mindspring.com ([209.86.5.50] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19KE5v-0005tI-00; Mon, 26 May 2003 02:16:41 -0700 Message-ID: <3ED1DA6A.E794010@mindspring.com> Date: Mon, 26 May 2003 02:12:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brad Knowles References: <20030525061524.H30007@sasami.jurai.net> <20030525084629.R30007@sasami.jurai.net> <20030525222955.GA826@athlon.pn.xcllnt.net> <20030525190744.A86964@sasami.jurai.net> <20030526001924.GA1272@athlon.pn.xcllnt.net> <20030525202140.Y86964@sasami.jurai.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43a67a386df8456166a32f68162cff307667c3043c0873f7e350badd9bab72f9c350badd9bab72f9c cc: current@FreeBSD.ORG cc: "Matthew N. Dodd" cc: Marcel Moolenaar Subject: Re: Preliminary ELF prebinding patches available. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2003 09:16:44 -0000 Brad Knowles wrote: > At 10:31 PM -0700 2003/05/25, Marcel Moolenaar wrote: > > Hence, prebind information is decoupled from the executable. One > > of the more obvious complexities is the fact that the naming scheme > > is such that multiple binaries can have the same prebind cache file. > > The collision is currently not handled, other than making sure that > > the prebind information for binary A1 is not used by binary A2. But > > other complexities exist. What if by some unlucky draw of faith you > > have two totally independent executables that both resolve to the > > same prebind file *and* happen to have the same build ID? You have > > an undetectable collision. > > How painful would it be to do a checksum (ideally, MD5 hash) of > the binary in question? Or at least recording path to the binary > within the prebind cache file? Or maybe file metadata like the > ownership, permissions, and date/time stamp? A hash is a bad idea. To check it, you would have to read all the pages, and lose your speed win from the pre-binding. 8-). Much better to use the inode number, device ID, and timestamp (the first two to verify a matching file, the last to reset the cache, should the file change). Personally, I prefer putting the information in an ELF section in the file itself; you're going to have a hell of a time with removing stale cache entries, without any tight coupling of what is, essentially, metadata. -- Terry