Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Russell King - ARM Linux wrote:
> On Wed, Jun 09, 2010 at 08:51:07AM +1200, 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.
> 
> Have you tried to use this stripped back defconfig file?

No, I haven't. I'm guessing it doesn't work straight off, but the point
is that the defconfigs do contain a lot of unneeded noise.

>> I think deleting defconfigs is a good first step. Although there will be
>> diffstat noise, it will also be clear that the net result is that
>> thousands of lines are being removed, which is a good thing.
> 
> You're forgetting that if the defconfigs go, then kautobuild might as
> well be taken offline because it'll have nothing to build.  It also
> means it'll be pointless participating in the build side of linux-next
> since that too won't have any useful build coverage.

I'm not suggesting deleting all of the defconfigs, I meant removing them
until we have one or two per mach directory. I haven't used kautobuild,
but surely having to build less kernels to support the same number of
boards is good?

Getting the defconfigs down to one or two per mach is, IMHO, a good
first step. Whatever gets decided as the best approach from there will
be easier since it will be a case of migrating ~30 defconfigs to the new
format rather than ~170. It also has the side effect benefit getting
developers to start writing the mach directories with single kernel
building in mind.

The SPEAr300, for example, couldn't be built into one kernel because of
a bunch of naming conflicts in #defines, etc. The patch series I posted
makes it possible to build all of them into one basically by doing a
mass rename. Yeah, I know, more noise :-), but the result is better. If
we do it once, and do it now, and enforce stricter rules in the future,
then the noise will be far greatly reduced in future, at the cost of
slightly noisier diffstats while it all gets fixed.

~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