Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Wed, 9 Jun 2010, Ryan Mallon wrote:

> 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.

Let's say it doubles.  So 20 lines instead of 10, which is still 
readable and much much smaller than defconfigs.

But the real solution in this case would be to have another 
Kconfig keyword to automatically select the needed dependencies.

> Granted, the list will be smaller than a
> defconfig file, but the Kconfig files are going to become substantially
> larger with this approach.

Sure.  But there is no problem with that if the growth is made of 
valuable information, which in my example I think it is.


Nicolas