Prev: menuconfig: fix to center checklist correctly in a corner case
Next: [PATCH -next] classmate-laptop: fix for RFKILL=m, CMPC=y
From: Tony Lindgren on 3 Jun 2010 12:50 * Linus Torvalds <torvalds(a)linux-foundation.org> [100603 17:48]: > > So I _think_ whatever "mach-xyz" file _should_ do something like > > # Kconfig file for OMAP4ABCXYZ chip > > .. set the particulars for this _particular_ chip, > ie select the particular drivers on this chip .. > > include "chip-family-details" (ie maybe "base OMAP details") > > include "architecture-family-details" (ie ARM Kconfig) > > see? Not one flat file, and very much not something generated. > > And I actually suspect we could do it with our current Kconfig file model. > IOW, in the arch/arm/Kconfig file, I think it should be doable to have > basically a > > choice > prompt "ARM platform" > > config ARM_PLATFORM_OMAP > bool PLATFORM_OMAP > > config ARM_PLATFORM_MSM > bool PLATFORM_MSM > ... > endchoice > > if ARK_PLATFORM_OMAP > include "Kconfig.omap" # this will further have choices for OMAP versions > elif ARM_PLATFORM_... > > and then the individual "Kconfig.platform" files could select certain > options, and then do a "include Kconfig.cpu" which would actually be the > _current_ top-level arch/arm/Kconfig. Some of this work has been already done like I responded in the other thread. So we could use the current omap3_defconfig for omap2, 3 & 4 with some more work. Then do the same thing for omap1. That would cut it down by total of 38 defconfigs. 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. > And I don't think we can get there from here unless I at some point say "I > just removed the xyz_defconfig files", at which point people will curse me > and stumble about until they actually come up with something better. > > Of course, if the ARM people do something proactive like the above > _before_ I remove the defconfig files, I won't complain. Whenever you feel like it, please just go ahead and do: $ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | cut -d: -f1 | xargs rm 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 ;) 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: Russell King on 3 Jun 2010 14:20 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 and so the list goes on... > 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. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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: Russell King on 3 Jun 2010 14:20 On Thu, Jun 03, 2010 at 07:48:18AM -0700, Linus Torvalds wrote: > So I _think_ whatever "mach-xyz" file _should_ do something like > > # Kconfig file for OMAP4ABCXYZ chip > > .. set the particulars for this _particular_ chip, > ie select the particular drivers on this chip .. > > include "chip-family-details" (ie maybe "base OMAP details") > > include "architecture-family-details" (ie ARM Kconfig) > > see? Not one flat file, and very much not something generated. Umm... > And I actually suspect we could do it with our current Kconfig file model. > IOW, in the arch/arm/Kconfig file, I think it should be doable to have > basically a > > choice > prompt "ARM platform" > > config ARM_PLATFORM_OMAP > bool PLATFORM_OMAP > > config ARM_PLATFORM_MSM > bool PLATFORM_MSM > ... > endchoice Umm. I don't think you've actually looked at the Kconfig files if you're writing this, because that's precisely what we already do. arch/arm/Kconfig has a big choice statement in it to select the machine class, and then it sources the individual arch/arm/*/Kconfig files, which are themselves wrapped in a if FOO foo's options endif It's not one huge big "let's source everything and hope people ignore options which don't apply to their platform" that you seem to be implying we are doing. The big problem with doing away with the defconfig files is more to do with what happens _outside_ of arch/arm. At one time, I was phasing IDE out, and didn't want to see the "IDE" configuration options on platforms which either never had IDE support or had had IDE support removed - unfortunately I was overruled by the IDE/ATA developers and the conditionals we had went away. That's just one instance, but consider when you're presented with thousands of driver and filesystem configuration options as is the case with modern kernels. How do you find the few options you need to get to a point that the kernel you've built is actually useful? Anyway, I thought we were discussing _defconfig_ files, not Kconfig files... What we _could_ to is introduce a: config STD_CONFIG bool "Enable me to generate a standard configuration for your platform" and then have platforms conditionally select everything that's appropriate for their use. That provides a way to avoid the ages old issue of select forcing options on, but the user still being presented with the option and being told the only possible value for it is 'y'. And yes, it _is_ necessary - because if you want to turn off something on the platform - eg, you're not using MMC and MMC fails to build - you can still end up with a working configuration at the end of the day. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- 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 14:30 On Thu, 2010-06-03 at 19:10 +0100, Russell King wrote: > config STD_CONFIG > bool "Enable me to generate a standard configuration for your platform" > > and then have platforms conditionally select everything that's > appropriate for their use. That provides a way to avoid the ages old > issue of select forcing options on, but the user still being presented > with the option and being told the only possible value for it is 'y'. > > And yes, it _is_ necessary - because if you want to turn off something > on the platform - eg, you're not using MMC and MMC fails to build - > you can still end up with a working configuration at the end of the > day. Check out the SAT solver link I quoted in the prior email.. That sounds like a really interesting solution. The defconfigs would ultimately hold just what's unique to a given board, then the solver would figure out what to else to enable just from those unique properties. So we would still have defconfigs , but they would not have loads of duplication like they do now. I don't see how we can do without defconfigs altogether tho. I mean , if you want to run a Beagle board or a Nexus one we can't just give the users a slim ARM config and let them troll through 1000's of drivers trying to find just those ones that work on their given board. 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: Linus Torvalds on 3 Jun 2010 14:30
On Thu, 3 Jun 2010, Russell King wrote: > > Umm. I don't think you've actually looked at the Kconfig files if you're > writing this, because that's precisely what we already do. ... but if you do this _right_, then the defconfig files would be unnecessary. That's my point. If you are right, then I can remove the defconfig files entirely. Are you ready for that? And if you aren't ready for that, then what was the point of your email? 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/ |