From mboxrd@z Thu Jan 1 00:00:00 1970 From: ryan@bluewatersys.com (Ryan Mallon) Date: Wed, 09 Jun 2010 09:32:20 +1200 Subject: Heads up: Linus plans to kill ARM defconfigs In-Reply-To: <20100608212253.GJ25370@n2100.arm.linux.org.uk> References: <4C0853E1.1080005@bluewatersys.com> <20100604061034.GI6499@atomide.com> <20100608115832.GB25370@n2100.arm.linux.org.uk> <4C0E3CAF.4050409@weinigel.se> <20100608131007.GE25370@n2100.arm.linux.org.uk> <4C0EAD3B.8010404@bluewatersys.com> <20100608212253.GJ25370@n2100.arm.linux.org.uk> Message-ID: <4C0EB6E4.3070900@bluewatersys.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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