Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Nicolas Pitre wrote:
> On Wed, 9 Jun 2010, Ryan Mallon wrote:
> 
>> Nicolas Pitre wrote:
>>> On Wed, 9 Jun 2010, Ryan Mallon wrote:
>>>
>>>> Striping the spitz defconfig back for example:
>>>>
>>>>   ryan at okiwi:configs$ wc -l spitz_defconfig
>>>>   1820 spitz_defconfig
>>>>
>>>>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
>>>> "^#" | wc -l
>>>>   641
>>>>
>>>> So removing all the comments and non-set options makes the defconfig
>>>> about 1/3 the size. If the defconfigs were generated by hand, or a
>>>> proper set of tools, then they could be much less verbose and diffs for
>>>> things like adding or removing a single config option would actually be
>>>> readable.
>>>>
>>>> If we want to have individual board configurations in the kernel, then
>>>> the information has to live somewhere. Whether it is defconfig, KConfig,
>>>> Documentation, whatever, the information will still take up a similar
>>>> amount of space, and the process of moving the information will generate
>>>> a load of diffstat noise.
>>> Did you see the SheevaPlug example I posted earlier?  It contains only 
>>> 10 lines of added information.  Certainly not similar amount of space to 
>>> the existing defconfig files.
>>>
>> Yes. I thought the problem was that Kconfig doesn't work correctly for
>> this though. Does having 'select MTD_PARTITIONS' automatically cause
>> CONFIG_MTD to be set? If not, then you basically need to have the full
>> config option list, which is basically what defconfig is.
> 
> Please read my email again and ponder on the rule of thumb I proposed to 
> decide what needs to be explicitly provided.

I agree that is probably a better solution than the defconfigs. However,
 your SheevaPlug example doesn't really show how big that config list is
going to get. Because Kconfig doesn't properly select dependencies, you
will have to list all of them. Granted, the list will be smaller than a
defconfig file, but the Kconfig files are going to become substantially
larger with this approach.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934