From: Ingo Molnar <mingo@elte.hu>
To: Adrian Bunk <bunk@kernel.org>
Cc: Florian Fainelli <florian.fainelli@telecomint.eu>,
linux-kernel@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] Add rdc321x defconfig file
Date: Mon, 25 Feb 2008 12:50:22 +0100 [thread overview]
Message-ID: <20080225115022.GA16376@elte.hu> (raw)
In-Reply-To: <20080225113235.GC32450@cs181133002.pp.htv.fi>
* Adrian Bunk <bunk@kernel.org> wrote:
> > What i do against build breakage is randconfig testing. That catches
> > far more build breakage than a few limited number of defconfigs
> > would ever.
>
> How do you test whether a x86 merge might break the compilation of
> e.g. some ARM platform without using any defconfig?
yes, we do test that too. (we added this recently)
> And building all defconfigs is the trivial way of having most
> reasonable configurations covered with only one day of compile time.
the existing 32-bit and 64-bit defconfigs should be enough for that. For
better/full coverage, randconfig should be used.
> > 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.
>
> My goal was "one per subarchitecture" which is not such a big number.
at least on x86 subarchitectures are not at all that important (they are
a rather inflexible build-time concept), and as you have seen it in this
thread, we are working on reducing their count. 99% of the real hardware
is covered under the generic subarchitecture.
they are more important on other (mostly embedded) platforms, with ARM
having 75 defconfigs.
Ingo
next prev parent reply other threads:[~2008-02-25 11:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-25 9:58 [PATCH] Add rdc321x defconfig file 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080225115022.GA16376@elte.hu \
--to=mingo@elte.hu \
--cc=bunk@kernel.org \
--cc=florian.fainelli@telecomint.eu \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.