Skip site navigation (1)Skip section navigation (2)
Date:      31 Jan 2002 14:02:26 -0000
From:      Mats Lofkvist <mal@algonet.se>
To:        tlambert2@mindspring.com
Cc:        n@nectar.cc, sheldonh@starjuice.net, arch@FreeBSD.org
Subject:   Re: Adding support for a global src tree serial number
Message-ID:  <20020131140226.12792.qmail@kairos.algonet.se>
In-Reply-To: <3C5947DC.DB3AD4B2@mindspring.com> (message from Terry Lambert on Thu, 31 Jan 2002 05:34:20 -0800)
References:  <79300.1012474898@axl.seasidesoftware.co.za> <20020131131714.GA87780@madman.nectar.cc> <3C5947DC.DB3AD4B2@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020131140226.12792.qmail>