From: Arnd Bergmann <arnd@arndb.de>
To: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
Cc: mathieu.poirier@linaro.org, linux-kernel@vger.kernel.org,
grant.likely@secretlab.ca
Subject: Re: [PATCH] ARM: versatile: automatically pick a board in Kconfig
Date: Fri, 9 Mar 2012 13:44:52 +0000 [thread overview]
Message-ID: <201203091344.52883.arnd@arndb.de> (raw)
In-Reply-To: <20120306231306.GE15201@n2100.arm.linux.org.uk>
On Tuesday 06 March 2012, Russell King - ARM Linux wrote:
> On Tue, Mar 06, 2012 at 03:49:22PM -0700, mathieu.poirier@linaro.org wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > The versatile platform supports building any combination of the
> > three board types (AB, PB, DT), but at least one of them has
> > to be enabled. This adds the necessary Kconfig statement to
> > enforce that at least one of the three is selected.
>
> This approach to 'fixing' the Kconfig doesn't scale particularly well
> when we've got lots of platforms to deal with.
>
> I much prefer using KALLCONFIG= to seed allno/allyes/allmod/rand configs.
> If you want to target a particular SoC you have to do that anyway. And
> you have to use that to ensure that you get a sane config state so that
> Kconfig doesn't try and ask for the PHYS_OFFSET value - it will decide
> to make that empty and then refuse to reprocess the Kconfig when you
> try to build the kernel.
>
> So I don't think there's any point to adding stuff like this.
I don't like the this particular way of working around Kconfig too
much either, but I would really like to see it get resolved in a way
that lets randconfig pick an arbitrary set and still finish the
build. Two other ways to get there that I can see are:
* Add a "multichoice" keyword in Kconfig that lets you write a
list of which at one or more items can be enabled, but not all
disabled. This might be the cleanest solution but it will take
some time to get implemented and have everyone convinced that it's
actually a good idea.
* Remove the ASSERT() for missing machine types, and if possible turn
it into a warning instead. This one would be for you to decide.
I think hardcoding the combination of boards using KCONFIG_ALLCONFIG
is not ideal because that will not fail to catch a lot of real bugs
that I found for unexpected combinations of boards.
Arnd
prev parent reply other threads:[~2012-03-09 13:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-06 22:49 [PATCH] ARM: versatile: automatically pick a board in Kconfig mathieu.poirier
2012-03-06 23:02 ` Grant Likely
2012-03-06 23:13 ` Russell King - ARM Linux
2012-03-09 13:44 ` Arnd Bergmann [this message]
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=201203091344.52883.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mathieu.poirier@linaro.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 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.