On Sun, 14.11.2010 at 21:57:25 +0100, Erik Cederstrand wrote: > > Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: > > > On 2010-11-14 21:22, Erik Cederstrand wrote: > >> I'm curious as to why this might be useful? Would the mtime of the > >> file not be be sufficient? I can only think of debugging purposes, but > >> apart from the timestamp, two kernels with the same rev. would be > >> bitwise identical, > > > > This does not have to be the case. For example, if you have have local > > modifications, or use different settings in make.conf or src.conf. > > In this case the timestamp + rev. is not sufficient to reproduce the kernel > anyway. You'd need to store externally the non-standard contents of conf > files, local diffs etc. on all your non-standard builds. You could do all > sorts of fun stuff, even fool the rev. number or timestamp if you wanted. > > I'm just saying that for the standard user on a standard GENERIC kernel (and > world for that matter) - the revision number should be sufficient for e.g. > filing a PR. If you need the timestamp, there's the mtime.
It might not be very easy, going from revision to timestamp. It is still very useful to know the rough timeframe when a kernel was built, as that might give you the "age" of the source tree. This is of course not a very good mapping, and the reason we have both the revision number in there, but also something a human understands. If this timestamp must be fixed, my vote would be on using the timestamp of the svn revision the build was using as a source. But it should be made clear, that this is then no longer the built timestamp, but the source repo timestamp. Uli
smime.p7s
Description: S/MIME cryptographic signature
