Date: Mon, 26 May 2003 02:12:10 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: Preliminary ELF prebinding patches available. Message-ID: <3ED1DA6A.E794010@mindspring.com> References: <20030525061524.H30007@sasami.jurai.net> <xzpaddb8ab8.fsf@flood.ping.uio.no> <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> <a0600125cbaf78024ba67@[10.0.1.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ED1DA6A.E794010>