IOW: can we switch the default of CONFIG_NODATESTAMP ?
Clearly, somebody has already thought about stripping the date from .configs, but it seems to me that this has been forgotten, and warrants a fresh look. - I searched http://marc.theaimsgroup.com/?l=kbuild-devel&r=1&b=200604&w=2 for CONFIG_NODATESTAMP, got *no* hits. How long ago was this added ? Since it has been so long, I'll state some obvious benefits of dropping the date: - its the date of the last 'save' or make oldconfig (true even w.o changes), - not the last real change made, compiled, installed, tested. - ls -l would tell the same, - cvs/../git would tell *much* more. IE its usually a meaningless difference If we drop it, then we get: - less noise when comparing configs - each config is unique and fingerprintable. - kernel gets the configure-print, builtin, as /proc/config.md5 or something. - this fingerprint is orthogonal to CONFIG_MODULE_SRCVERSION_ALL This has Many Implications - 'known' configs Each kernel release 'creates' a bunch of known configs (A*S*M of them) A - all the arches S - each arch's sub-arches M - make-targets: allnoconfig, allyesconfig, allmodconfig, etc With date gone, these are trivially reproducible, byte for byte. Bug reports with attached config-vs-x86-64-all-defaults.diff become meaningful, and arguably better than straight attachments (since theyre shorter, and refer to a well understood (and completely repeatable) standard). 'make standard-configs' This notional target would generate a set of M standard configs, and name them appropriately: config-$M foreach $M (@maketarget) Just recently on LKML, Adrian Bunk rightly complained about a bug-report with a partial .config, since its tedious to reproduce the problem, and OP noted he didnt want to 'spam' the list. If the OP had seen a config-alldefaults file in his build-directory, he would likely have sent a diff against it, and Adrian would have a way to reproduce it. Blue-Sky / Garden-Path As releases happen, these reference configs could be stored to SCM, with references to previous releases. The changes that are tracked this way are the cumulative results of all the accepted/committed work. - QA (extra hand-wavery here) When bugs are filed, the dmesg should/will contain a config-md5. The md5 will instantly tell us if its a vanilla config, or tinkered and tweaked one. Suppose a kernel gets out the door with a missing kconfig dependency, if the 1st 5 bug-reports have a config.diff-vs-$MyArch-alldefaults, it should help streamline/automate the corrective procedures, which Id describe currently as: Andrew Morton emails X about his problem. (perhaps described currently as: MM emails X) config.diffs that expose missing dependencies can become regression tests. If configs are permuted and (re)-generated, fingerprints can be taken, along with a status (randomly-generated). If/when these configs are compile-tested, errs also become regression tests. - make config-print gather status: the configureprint, installed and running status, whatevers relevant, and send to [EMAIL PROTECTED] -rcX and -mm trees could conceivably benefit from information pumped back by interested hackers (esp if its easy as 'make qa') -- a config-spectrum-analyser Even though the md5 doesnt say much about what features are being configured into a submitters kernel, it is enough to 'histogram'. Doing so would show us the distribution of configurations being tested over a given period. WRT test coverage, a very spiky 'config-spectrum-analysis' would support the view that in -MM, all CONFIG_ items should default to [YM], so at least the code gets built. Extreme spikiness might highlight the need for a kind of [EMAIL PROTECTED] project, which just distributes a permute-and-test task amongst available machines. Sounds too much like PR fodder, but... Ill stop here, ( I may have floated too many half-described ideas already) What do we need to do to bury the date ? Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
