Messages in this thread |  | | Date | Tue, 26 Feb 2008 21:30:53 +0100 | | From | Ingo Molnar <> | | Subject | Re: [PATCH] Add rdc321x defconfig file |
| |
* Sam Ravnborg <sam@ravnborg.org> wrote:
> > Subarchitectures on x86 are just a shortcut for the "0.1% of systems > > that were lazy to be properly abstracted into the general PC code". We > > are discouraging additional subarches and the one that got added > > recently will go away soon. The rest is legacy. > > So you say we would waste our time doing build test of the legacy > sub-archs. OK.
definitely if what you want to do is to use your compilation resources to increase the quality of a patch as efficiently as possible. Testing UP/SMP 32bit/64bit defconfig and allnoconfig catches most of the immediate problems - allmodconfig will catch most of the rest. If you want to catch _all_ bugs that are possible the .config space, then 20 randconfig builds give a higher than 99.9% confidence factor already, in my experience.
Sometimes, very rarely, deep down the chain of some really quirky Kconfig dependencies, there can be up to 1:512 chance build bugs hiding, which statistically need a 1000 randconfig builds to trigger. I saw a few in the past, but they are really rare. No amount of pre-cooked defconfigs would cover them - they are usually in drivers, not in subarch support.
what would be really useful is an automatic Kconfig tree analysis, with the printing out of too deep dependencies perhaps? Which might result in the breaking down of too deep dependencies - to increase the coverage of randconfig testing. Sometimes the number of "depends on" conditions are mind-blowing.
Ingo
|  |