ARM defconfig files
in [Kernel]
|
Prev: menuconfig: fix to center checklist correctly in a corner case
Next: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y
From: Linus Torvalds on 3 Jun 2010 16:40 On Thu, 3 Jun 2010, Linus Torvalds wrote: > > I apparently haven't explained myself enough, because what you keep on > harping on is not something I consider acceptable. > > STD_CONFIG is pointless. It's pointless because the solution to what > you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz > file at all. To make this _really_ concrete, let me actually give you an example (but broken and pointless) example Kconfig file, in order to _avoid_ having a def_config file. I do it by generating it. Let's say that I want a x86 configuration that has USB enabled. I can basically _ask_ the Kconfig machinery to generate that with something like this: - create a "Mykconfig" file: config MYCONFIG bool default y select USB source arch/x86/Kconfig and then I just do KBUILD_KCONFIG=Mykconfig make allnoconfig and look what appears in the .config file. In fact, do this: make allnoconfig cp .config no-config KBUILD_KCONFIG=Mykconfig make allnoconfig cp .config my-config diff -u no-config my-config to see the point of it all. Now, the above is a _trivial_ one. And it's actually broken, because I should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT). But with this approach you could basically generate the defconfig files. And exactly because Kconfig files are already hierarchical, you can do things like - Kconfig.omap3_evm: # Set the OMAP3 EVM-specific parts config OMAP3EVM bool default y select OMAP3_EVM_TIMERS # whatever ... # this sets the thngs all OMAP3 cases want source Kconfig.omap3 - Kconfig.omap3 # Set the OMAP3 specific parts config OMAP3 bool default y select USB_SUPPORT select USB ... source Kconfig.arm and now you'd be able to basically generate a OMAP3EVM .config file by just running "allnoconfig" on that Kconfig.omap3_evm file. But it would only have to select the parts that are specific for the EVM platform, because the generic OMAP3 support would be picked by the Kconfig.omap3 file, which in turn would not have to worry about the generic ARM parts etc. See? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 3 Jun 2010 17:20 * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 23:30]: > > and now you'd be able to basically generate a OMAP3EVM .config file by > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would > only have to select the parts that are specific for the EVM platform, > because the generic OMAP3 support would be picked by the Kconfig.omap3 > file, which in turn would not have to worry about the generic ARM parts > etc. > > See? Sounds like a good improvment to me. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 3 Jun 2010 17:40 * Russell King <rmk(a)arm.linux.org.uk> [100603 21:07]: > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote: > > Compiling in multiple ARM platforms is trickier, we would have to get > > rid of the duplicate defines like NR_IRQS, then have some common clock > > framework etc. Then figure out some way to get rid of Makefile.boot. > > Russell probably has some other things in mind that would have to be > > changed to make this happen. > > - Find someway to handle the wide variety of interrupt controllers. > - Be able to handle any multitude of V:P translations, including non-linear > alongside linear transations. > - Different PAGE_OFFSETs > - Different kernel VM layouts allowing for a variety of different ioremap > region sizes Some of these could be handled by allowing building a seprate instance for each platform compiled in. Maybe we could set them up with symlinks. How about a minimal generic relocatable ARM kernel and then we load the platform support as a module from ramdisk? :) > and so the list goes on... Yeah.. > > That way maybe you can wait a bit longer for the other defconfigs > > and as an extra bonus I won't get flamed for removing these omap > > defconfigs ;) > > Note that Linus is talking about removing all but one or two ARM > defconfigs - which means your omap3_defconfig will probably be > eventually culled. Yes but I also think we need to do something about this. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 3 Jun 2010 17:50 On Thu, 2010-06-03 at 13:31 -0700, Linus Torvalds wrote: > and now you'd be able to basically generate a OMAP3EVM .config file by > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would > only have to select the parts that are specific for the EVM platform, > because the generic OMAP3 support would be picked by the Kconfig.omap3 > file, which in turn would not have to worry about the generic ARM parts > etc. > > See? We could just alias commands so when the user runs "make ARCH=arm omap3_evm_defconfig" it would just do whatever this command does , "KBUILD_KCONFIG=arch/arm/configs/Kconfig.omap3_evm make allnoconfig" but those Kconfigs wouldn't be in "make menuconfig" it would just exist to generate the defconfigs, or the .config .. So Kconfig.omap3_evm basically becomes the defconfig. That doesn't seem un-reasonable. Although the solver to me seems more elegant and we're getting the solver for some other reasons it seems (unrelated to this defconfig issue). Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Grant Likely on 3 Jun 2010 18:20
On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <tony(a)atomide.com> wrote: > * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 23:30]: >> >> and now you'd be able to basically generate a OMAP3EVM .config file by >> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would >> only have to select the parts that are specific for the EVM platform, >> because the generic OMAP3 support would be picked by the Kconfig.omap3 >> file, which in turn would not have to worry about the generic ARM parts >> etc. >> >> See? > > Sounds like a good improvment to me. (as one who just finishing updating powerpc defconfigs...) ditto here. I'd be happy to be rid of all the existing ppc defconfigs. I like the Kconfig approach, but to be useful (at least for me) there would need to be a way to get Kconfig to complain about things like broken selects as in your example. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |