LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Sam Ravnborg <>
Cc: Adrian Bunk <>,
	Florian Fainelli <>,,
	Thomas Gleixner <>,
	"H. Peter Anvin" <>
Subject: Re: [PATCH] Add rdc321x defconfig file
Date: Tue, 26 Feb 2008 10:44:51 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Sam Ravnborg <> 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, and a 300,000+ sample 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 It's that simple, 


  reply	other threads:[~2008-02-26  9:45 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25  9:58 Florian Fainelli
2008-02-25 10:14 ` Ingo Molnar
2008-02-25 10:24   ` Florian Fainelli
2008-02-25 10:51     ` Ingo Molnar
2008-02-25 11:03       ` Florian Fainelli
2008-02-25 11:17       ` Adrian Bunk
2008-02-25 11:27         ` Florian Fainelli
2008-02-25 11:45           ` Adrian Bunk
2008-02-25 11:54             ` Ingo Molnar
2008-02-25 11:08   ` Adrian Bunk
2008-02-25 11:17     ` Ingo Molnar
2008-02-25 11:32       ` Adrian Bunk
2008-02-25 11:50         ` Ingo Molnar
2008-02-25 12:25           ` Adrian Bunk
2008-02-25 12:57             ` Ingo Molnar
2008-02-25 13:12               ` Adrian Bunk
2008-02-25 13:45                 ` Ingo Molnar
2008-02-25 14:09                   ` Adrian Bunk
2008-02-25 19:02       ` Sam Ravnborg
2008-02-26  9:44         ` Ingo Molnar [this message]
2008-02-26 20:14           ` Sam Ravnborg
2008-02-26 20:30             ` Ingo Molnar
2008-02-27  6:49               ` Adrian Bunk
2008-02-27 18:31               ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] Add rdc321x defconfig file' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).