From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Building for MMU-less vexpress targets
Date: Wed, 7 Nov 2012 12:59:14 +0000 [thread overview]
Message-ID: <201211071259.15107.arnd@arndb.de> (raw)
In-Reply-To: <20121106221437.GQ28327@n2100.arm.linux.org.uk>
On Tuesday 06 November 2012, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 09:14:49PM +0000, Arnd Bergmann wrote:
> > The other point is being able to build such a kernel, and this is what Will
> > seems to be interested in more. We have made VEXPRESS depend on
> > MULTIPLATFORM, which broke support for building a non-MMU vexpress kernel,
> > and I think we should fix that. The two options are either to make
> > vexpress be single-platform when building for !MMU, or to allow multiplatform
> > kernels to be built without MMU support in principle. I think the second
> > option is more logical and avoids complex Kconfig constructs.
>
> The other thing here is... why does a platform which _was_ able to be
> built in isolation from every other platform suddenly become incapable
> of being so when they join the multiplatform conglomerate? This just
> sounds totally perverse and wrong.
>
> Surely it should be: platforms _not_ yet converted to multiplatform
> can't be selected with multi-platform support enabled?
>
> So, maybe the _proper_ solution here is:
>
> - change the big choice to be: config SINGLE_xxx
> - these select config MACH_FOO / PLAT_FOO / ARCH_FOO
> eg,
> config SINGLE_FOO
> bool "Support for foo platforms in single kernel"
> select MACH_FOO
> - add a final option: config MULTIPLATFORM
> - then add:
>
> config MULTI_FOO
> bool "Include support for foo platforms"
> select MACH_FOO
> depends on MULTIPLATFORM || !MMU
> ...
>
> config MACH_FOO
> bool
A few platforms are doing this. E.g. the vt8500 platform currently
allows both, and the at91 will only allow multiplatform to be selected
for the DT-aware systems, while the single-platform still allows both
DT and non-DT. In general, I'm fine with either approach (multiplatform
only or mixed) and I'd like to leave that choice to the platform
maintainers.
> Now, we don't _have_ to have the single and multi variants if they aren't
> appropriate for the platform, but we can cover all the cases: a platform
> where it's part of the multi-platform kernel when built for MMU, but is
> incapable of being a multi-platform kernel when built without MMU.
>
> And we can do it without _too_ much Kconfig pain, and certainly without
> having to delve into anything beyond arch/arm/Kconfig.
Sure, that works. My point was just that I think it would be simpler
to keep vexpress multiplatform-only if there are no reasons that prevent
us from doing that.
I also hope that we can at some point in the future get all ARMv6 and ARMv7
platforms to be multiplatform-only, while leaving each ARMv4/ARMv5 to be
any of single, multi, or mixed.
> I'd suggest at that point we separate out this stuff into a separate
> file - arch/arm/Kconfig.mach, which contains all the platform selection
> stuff.
Good idea, I like that.
Arnd
next prev parent reply other threads:[~2012-11-07 12:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 17:36 Building for MMU-less vexpress targets Will Deacon
2012-11-05 18:03 ` Pawel Moll
2012-11-05 18:13 ` Will Deacon
2012-11-05 19:08 ` Arnd Bergmann
2012-11-06 12:20 ` Will Deacon
2012-11-06 17:33 ` Arnd Bergmann
2012-11-06 18:34 ` Will Deacon
2012-11-06 20:35 ` Arnd Bergmann
2012-11-06 20:58 ` Nicolas Pitre
2012-11-06 21:14 ` Arnd Bergmann
2012-11-06 22:14 ` Russell King - ARM Linux
2012-11-06 22:59 ` Rob Herring
2012-11-07 12:59 ` Arnd Bergmann [this message]
2012-11-07 13:39 ` Russell King - ARM Linux
2012-11-06 23:14 ` Nicolas Pitre
2012-11-07 10:21 ` Will Deacon
2012-11-07 13:29 ` Arnd Bergmann
2013-01-08 19:01 ` Jonathan Austin
2013-01-08 19:11 ` Arnd Bergmann
2013-01-08 19:22 ` Nicolas Pitre
2012-11-06 22:51 ` Jamie Lokier
2012-11-06 23:40 ` Nicolas Pitre
2012-11-06 23:46 ` Jamie Lokier
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=201211071259.15107.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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.