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 -- 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
