Re: [PATCH] Add rdc321x defconfig file

From: Ingo Molnar
Date: Tue Feb 26 2008 - 04:45:33 EST



* Sam Ravnborg <sam@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/