RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU

From: Nicolas Pitre <nicolas.pitre@linaro.org>
To: Chris Brandt <Chris.Brandt@renesas.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Russell King <linux@armlinux.org.uk>,
	Greg Ungerer <gerg@linux-m68k.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: RE: [PATCHv4 4/4] ARM: versatile: support configuring versatile machine for no-MMU
Date: Fri, 22 Jun 2018 13:05:25 -0400 (EDT)	[thread overview]
Message-ID: <nycvar.YSQ.7.76.1806221244490.16670@knanqh.ubzr> (raw)
In-Reply-To: <TY1PR01MB15624342267F973525BF45698A750@TY1PR01MB1562.jpnprd01.prod.outlook.com>

On Fri, 22 Jun 2018, Chris Brandt wrote:

> On Friday, June 22, 2018 1, Nicolas Pitre wrote:
> > All that is possible already. But config symbol mutual exclusion is not.
> 
> I still don't understand why we need some false sense of security for 
> only selecting 1 platform.

Because that's the right thing to do. Small hacks are nice, but when 
they accumulate (and they always do over time) then maintainability 
suffers. This is why you may do whatever small hacks in your own copy of 
the kernel code and that might be good enough, but the mainline source 
tree should be held to higher standards.

> There are probably plenty of kernel config options that you could enable
> that would break any number of systems.

That's no excuse to add more of them. Many people are constantly working 
to move things in the other direction.

> So, why do we feel that XIP_KERNEL needs a warm safety blanket around 
> it?

Because we simply try not to create invalid kernel configurations. 
XIP_KERNEL is not more special than other symbols in that respect.

And if the kconfig language has to be extended for proper configurations 
to be produced then that's what it is, and trying to cheat around that 
fact won't produce any good.

Nicolas