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 13:29:26 +0000 [thread overview]
Message-ID: <201211071329.26995.arnd@arndb.de> (raw)
In-Reply-To: <alpine.LFD.2.02.1211061802240.21033@xanadu.home>
On Tuesday 06 November 2012, Nicolas Pitre wrote:
> On Tue, 6 Nov 2012, Arnd Bergmann wrote:
>
> > On Tuesday 06 November 2012, Nicolas Pitre wrote:
> > > I really think that it makes no sense at all to support !MMU kernels in
> > > a multi-platform kernel build, even if the set of included platforms
> > > were all !MMU. The kernel has to be linked for the physical address of
> > > the target and not a common invariant virtual address.
> >
> > There are two separate aspects here: One is to run a kernel on !MMU that is
> > built to support multiple platforms. I agree that this is rather pointless
> > and not interesting.
> >
> > The other point is being able to build such a kernel, and this is what Will
> > seems to be interested in more.
>
> What's the point of building a pointless and uninteresting kernel?
Built-time coverage is the only one I can think of, but I think it's a
good reason. Being able to build an "allyesconfig" with MMU disabled
sounds like a good sniff test to see if something broke and is much faster
than building all the defconfigs.
> > 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.
>
> Well, I'd rather prefer to think that the first option is the most
> logical between those 2 options, regardless of Kconfig complexity
> issues.
>
> I didn't look, but just making MULTIPLATFORM depend on !MMU, and
> VEXPRESS depend on MULTIPLATFORM || MMU should be close to what is
> needed, no?
Fine with me too. I suppose you just made the same logic error that
I had earlier in this thread and meant !MMU where you wrote MMU.
Arnd
next prev parent reply other threads:[~2012-11-07 13:29 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
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 [this message]
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=201211071329.26995.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.