From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Dan Kegel <dank@kegel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Fix allnoconfig on arm with small tweak to kconfig?
Date: Mon, 13 Sep 2004 19:51:19 +0100 [thread overview]
Message-ID: <20040913195119.B4658@flint.arm.linux.org.uk> (raw)
In-Reply-To: <4145BB30.60309@kegel.com>; from dank@kegel.com on Mon, Sep 13, 2004 at 08:22:24AM -0700
On Mon, Sep 13, 2004 at 08:22:24AM -0700, Dan Kegel wrote:
> Russell King wrote:
> > On Mon, Sep 13, 2004 at 12:53:33AM -0700, Dan Kegel wrote:
> >
> >>'make allnoconfig' generates a broken .config on arm because
> >>none of the boolean CPU types get selected.
> >>ARCH_RPC *does* get selected ok, and I can make CPU_SA110 the
> >>default if ARCH_RPC, but that doesn't help, since allnoconfig
> >>sets all booleans that are exposed to the user to false, so
> >>CPU_SA110 remains false.
> >
> >
> > allnoconfig is broken. It doesn't generate a legal configuration on
> > this platform.
>
> I think that's what I said. I guess you're saying it more forcefully;
> you seem to be implying "the basic idea of allnoconfig is broken."
Indeed - we can go around fixing the configuration to work on each
individual machine type, but... have you checked how many platforms
there are, and are you volunteering to test the kernel configuration
for each one?
I can tell you that, eg, IDE makes sense on SA1100 platform X but
not Y or Z. Do we _really_ want to express this level of complexity
in the kernel configuration?
On ARM, there are over 500 platform types in the database (ok, not
all of them are merged or even exist anymore, but that's still a
substantial number.) It is obviously completely impossible to rig
up the Kconfig subsystem such that every platform has a valid
configuration.
> I guess it depends on your goals. My goal is to use allnoconfig
> as a toolchain regression test. For each arch, I want an easy way
> to build some kernel (any kernel!) for that arch. ARCH_RPC
> is the default on arm (yes, I know you think the whole
> concept of defaults on arm is broken), so it's the only one that
> needs fixing.
Well, you're going to run into the same problem with Versatile and
the Integrator class of platforms as well.
Basically, there's a fair amount of conditions under which Kconfig
fails to perform reasonably, and these (little used) targets are
an example of that.
If you want something that's guaranteed to work, use one of the
per-platform default configurations. Nothing else carries any
guarantee what so ever on ARM.
(Also, I have no interest in all*config myself so even if someone
does fix it, chances are it'll get broken again. I believe that
the concept of all*config is a fundamentally broken concept for an
architecture with numerous platform configurations.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2004-09-13 18:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 7:53 Fix allnoconfig on arm with small tweak to kconfig? Dan Kegel
2004-09-13 8:15 ` Russell King
2004-09-13 15:22 ` Dan Kegel
2004-09-13 18:51 ` Russell King [this message]
2004-09-13 19:29 ` Herbert Poetzl
2004-09-13 21:06 ` Nicolas Pitre
2004-09-13 21:34 ` Russell King
2004-09-14 1:42 ` Dan Kegel
2004-09-14 8:29 ` Russell King
2004-09-17 8:39 ` Dan Kegel
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=20040913195119.B4658@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox