From owner-freebsd-arch Thu Jan 31 6: 2:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from smtp.tninet.se (sheridan.tninet.se [195.100.94.102]) by hub.freebsd.org (Postfix) with ESMTP id 4616A37B404 for ; Thu, 31 Jan 2002 06:02:35 -0800 (PST) Received: from kairos.algonet.se (kairos.algonet.se [194.213.75.171]) by sheridan.tninet.se (BMR ErlangTM/OTP 3.0) with ESMTP id 851272.485748.1012.0s5448140sheridan for ; Thu, 31 Jan 2002 15:02:28 +0100 Received: (qmail 12793 invoked by uid 2493); 31 Jan 2002 14:02:26 -0000 Date: 31 Jan 2002 14:02:26 -0000 Message-ID: <20020131140226.12792.qmail@kairos.algonet.se> From: Mats Lofkvist To: tlambert2@mindspring.com Cc: n@nectar.cc, sheldonh@starjuice.net, arch@FreeBSD.org In-reply-to: <3C5947DC.DB3AD4B2@mindspring.com> (message from Terry Lambert on Thu, 31 Jan 2002 05:34:20 -0800) Subject: Re: Adding support for a global src tree serial number References: <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> <3C5947DC.DB3AD4B2@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > "Jacques A. Vidrine" wrote: >> = The serial number could be the MD5 of the source tree from which the >> system was compiled: >> tar -C /usr/src --exclude CVS -cf - . | md5 >> I'm currently running 4.5-RELEASE build 10c5be07ecd40c66fc126dd57afd934c. > Uh... are you sure a cryptographic hash of the source > you have is going to give enough information for a > kernel hacker to recreate the binaries that are causing > the problem that resulted in the bug report? > > I guess I could just check out by second since the start > of the source tree, until the hashes matched? > > 8-) 8-) 8-). > > -- Terry Maybe this wouldn't be as bad if the MD5 was done e.g. on a sorted list of file name - version number pairs? It would then be possible to create a tool that automatically tests all combinations given a list of all files and versions that existed in a given time interval. The fact that this explodes exponentially with number-of-files ^ average-number-of-versions probably makes it impractical for use with longer time intervals though :-) But, if you knew the exact order of changes, you could start with a list of all files with versions at the start time and then check the MD5 for all changes until the end time by replacing the version of each changed file. This is only number-of-files * number-of-changes. A combination of these two techniques could be used to get the speed from the later but still allowing for changes 'close enough' in time to be applied in random order. _ Mats Lofkvist mal@algonet.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message