Re: [PATCH v3 2/2] drivers: cleanup Kconfig stuff

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

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.