On Mon, Jun 26, 2006 at 04:04:24PM -0600, Jim Cromie wrote:
>...
> Since it has been so long, I'll state some obvious benefits of dropping
> the date:
>...
> 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
I don't see the big advantage of any of them.
> 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).
There are defconfigs for this purpose.
Since diff's aren't always shorter (they can even be significantely
larger) than the file.
At most times the .config alone is the important thing to read, only in
some rare cases the diff compared to another .config is the interesting
thing. And in the latter case, don't assume the person requiring it was
too dumb to use "diff" himself.
> 'make standard-configs'
>
> This notional target would generate a set of M standard configs, and
> name them
> appropriately: config-$M foreach $M (@maketarget)
Already present for ages, called defconfig.
> 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.
The size is not an issue.
And if it was, bzip2 would beat your proposal easily for this purpose.
> 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.
Call them defconfig, and it's already implemented.
> - 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.
Using a vanilla config wouldn't make sense for anyone.
> 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,
>...
Wrong.
diff's of .config's are harder to read than .config's.
> config.diffs that expose missing dependencies can become regression
> tests.
>...
These are usually bugs that don't occur again.
> -- 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.
>...
With the exception of distribution kernels, the probability that someone
else uses exactly the same .config I'm using is nearly zero, since the
number of possible different .config's on a given architecture is
something in the order of 2^1000 or one (american) billion.
> 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...
>...
Testing kernels is an important topic, but it can't work the way you
think of it.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
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
