linux-kernel - Re: [PATCH] Add rdc321x defconfig file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Feb 2008 21:30:53 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Adrian Bunk <bunk@...nel.org>,
	Florian Fainelli <florian.fainelli@...ecomint.eu>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] Add rdc321x defconfig file

* Sam Ravnborg <sam@...nborg.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/