On Fri, 22 Jun 2018, Geert Uytterhoeven wrote: > Hi Nicolas, > > On Fri, Jun 22, 2018 at 5:26 PM Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote: > > On Fri, 22 Jun 2018, Russell King - ARM Linux wrote: > > > On Thu, Jun 21, 2018 at 12:24:04PM -0400, Nicolas Pitre wrote: > > > > [ adding linux-kbuild for their input ] > > > > > > > > On Thu, 21 Jun 2018, Geert Uytterhoeven wrote: > > > > > I've just sent a patch to do that. > > > > > > > > Your patch isn't wrong per se. But it is not enough. The issue here > > > > would be easily fixed with some kconfig extension so that: > > > > > > > > - If XIP or NOMMU is selected then only one target in the multiplatform > > > > set can be selected, basically turning it into a choice menu. > > > > > > I don't think that's how it should work. Consider the V7M case, where > > > we have better standardisation of the physical address layout than > > > previous ARM devices. We have three platforms which are V7M compliant: > > > > > > - AT91 > > > - iMX > > > - STM32 > > > > > > These have separate symbols: > > > > > > menuconfig ARCH_AT91 > > > bool "AT91/Microchip SoCs" > > > depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V7 || ARM_SINGLE_ARMV7M > > > > > > menuconfig ARCH_MXC > > > bool "Freescale i.MX family" > > > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M > > > > > > menuconfig ARCH_STM32 > > > bool "STMicroelectronics STM32 family" if ARM_SINGLE_ARMV7M || ARCH_MULTI_V7 > > > > > > With your suggestion, you would become only build a kernel for one of > > > these, but that is not the case today: it's possible to build a single > > > kernel which supports all these platforms. > > > > That is still something that could be accommodated if the kconfig > > language was more accommodating. The problem comes from the fact that > > some options are mutually exclusive, like platforms with conflicting > > memory maps and XIP. > > > > Leaving your example above aside for the moment, let's just pick the > > ARCH_MULTIPLATFORM group which is always the problematic one in > > practice. We need a way to limit platform selection within that set to > > only one platform among them all if XIP_KERNEL is set. And that is > > impossible to express with the kconfig language today. > > > > So, my assertion is that, unless someone volunteers a solution to the > > kconfig language to express mutual exclusion between symbols, this issue > > just can't be fixed properly. > > Even that would not be sufficient, as these days the final target platform > selection is not by a Kconfig symbol, but by a DT[SB] file. That is no longer a kernel config/build issue if you the system integrator put an XIP kernel on a target with the wrong DT. The XIP kernel does require that you provide the actual memory base address as a constant to the build system but that could be extracted directly from the DT data if having a kconfig prompt for that is too unwieldy. The new kconfig macro language in mainline could even be leveraged to do that at config time. All that is possible already. But config symbol mutual exclusion is not. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
