On Tue, Nov 02, 2010 at 09:43:30PM +0200, Felipe Contreras wrote: > On Tue, Nov 2, 2010 at 4:35 PM, Mark Brown > > This solution doesn't seem like it scales so well either, it just shifts > > it into the Kconfig files (where everything is all in central files > > shared by everyone which has its own problems). Certainly the goal of > > replacing defconfig files with Kconfig seems unattainable. > The difference is that Kconfig files are needed, and part of linux > itself. The defconfig files should be optional, there are many, and > not necessarily in the linux tree (e.g. meego kernel configs). Right, but it's not like you're ever going to get a useful machine configuration just using Kconfig except in the most trivial systems. > However, even if you forget about Kconfig vs defconfig, it should be > possible to create a .config file from nothing, and when you do that, > having REGULATOR_TWL4030 enabled when you enable REGULATOR support > just makes sense (if you have enabled TWL4030_CORE). Right, but everyone uses the same Kconfig files while the defconfigs only affect the individual platform which uses them. This is annoying for me since it increases the amount of stuff that gets built into my kernel (I routinely build everything I possibly can in my subsystems for coverage but don't actually want to have all that stuff show up in the kernel image I'm running on my system). The stuff ends up built in due to the issue with MFDs not being buildable as modules since they have interrupt controllers, if that were fixed it wouldn't be an issue. If you're going to make this sort of change we need to have a policy change over all MFD subdevices (and possibly some other things) and decide that we'll eat the costs. Doing it randomly for individual chips and drivers within those chips doesn't seem like a good approach. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
