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]

Message-ID: <20080226094451.GL9857@elte.hu>
Date:	Tue, 26 Feb 2008 10:44:51 +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:

> And asking me to do randconfig is not an option. I have only this 
> machine to work on and with a -j8 build it gets unresponsive at least 
> so much that it irritates me.

> > More defconfigs would just be a constant maintenance drag, they are 
> > rather pointless on PC hardware anyway (we'd have to have at least a few 
> > hundred of them for it to be meaningful as a "default config") and it 
> > does not really solve the problem either.
>
> 10 different configs would cover what I have in mind. This is not all 
> sort of combinations of dirvers and kernel haching options multiplied 
> with the arch specific options. This is the typical set of options 
> that is used to build a kernel to the relevant sub-architectures.
> 
> And an occasional defconfig update are not a maintanence burden.
> 
> It is a simple equation: 10 additional defconfigs can give you more 
> build coverage by additional people. Is it worth it?

i dont think it's worth it on x86, because it has no real meaning so it 
will just be an arbitrary thing that deteriorates over time.

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.

Really, we should concentrate our testing to where our _testers_ are and 
where our developers are.

And according to lkml, http://kerneloops.org and a 300,000+ sample 
http://smolt.fedoraproject.org/static/stats/stats.html statistics, our 
testers are distributed like this:

 - more than 90% of all kernel developers use general PC hardware

 - more than 95% of our active testers use general PC hardware

 - more than 99.1% of our distro users that are willing to send us
   feedback use general PC hardware as well

(In that aspect i dont count the million(s?) of non-x86 Linux based 
phones as "a million users", unless they become an active part of our 
ecosystem and do things like hook into kerneloops.org. It's that simple, 
really.)

	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/