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