Heads up: Linus plans to kill ARM defconfigs

Nicolas Pitre nico at fluxnic.net
Tue Jun 8 19:31:50 EDT 2010


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.


Nicolas



More information about the linux-arm-kernel mailing list