On Tue, Jun 27, 2006 at 01:53:02PM -0600, Jim Cromie wrote:
> Adrian Bunk wrote:
> >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.
> >
>
> 'big' would be an overstatement, but this following property is un-good
>
> 1019 cp .config config-ok
> 1020 make oldconfig
> 1021 diff .config config-ok
>
> $ diff .config config-ok
> 4c4
> < # Mon Jun 26 19:29:21 2006
> ---
> > # Sun Jun 25 07:50:27 2006
>
> granted, its little more than a speed-bump, but we like smooth roads..
I'm getting the impression you are searching for non-existing
problems...
>...
> >>- '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.
> >
> That suggests they diff'd against the wrong thing.
> diffing vs allmodconfig will generally be *far* better than vs allnoconfig.
It seems you don't know what you are talking about.
With my .config and kernel 2.6.16.22:
35146 .config
67963 .config-allmodconfig
97572 diff-allmodconfig-myconfig
Yes, the diff has nearly three times the size of the .config ...
QED
>...
> >>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.
> >
> bzips are not readable as is, and folks with knowledge to recognize
> broken-ness
> may not have the inclination to unzip and see.
>
> Size was an issue for the OP, so he sent a fragment that he thought was
> the salient info.
> If he had several 'defconfigs', he could have diff'd them all,
> just to see which was the smallest, and sent that.
>
> This focus on size is unfortunate; its only an approximation of the real
> differences
> that may or may-not be a factor in the problem
The best solution is simply to send the .config .
All your suggestions make things more complicated for no good reason.
>...
> >>-- 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.
> >
> >
> yes - but most of them are probably precluded by the kconfig rules;
> hundreds of random configs will collapse to the same result once run
> thru 'make oldconfig'.
> This reduction seems mildly interesting in itself, for some value of
> interesting.
>...
No, these .config's will not collapse.
> thanks
> Jim Cromie
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
