From mboxrd@z Thu Jan 1 00:00:00 1970 From: ryan@bluewatersys.com (Ryan Mallon) Date: Wed, 09 Jun 2010 08:51:07 +1200 Subject: Heads up: Linus plans to kill ARM defconfigs In-Reply-To: <20100608131007.GE25370@n2100.arm.linux.org.uk> References: <4C083BCF.2060500@bluewatersys.com> <201006040310.15019.marek.vasut@gmail.com> <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> Message-ID: <4C0EAD3B.8010404@bluewatersys.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Russell King - ARM Linux wrote: > On Tue, Jun 08, 2010 at 02:50:55PM +0200, Christer Weinigel wrote: >> Linus isn't stupid. If you explain what you are doing and that the goal >> is to reduce the set of defconfigs to just one per processor family, and >> that it will reduce the churn in the end, I think Linus will listen. > > It's also not just about the number of defconfigs. Linus had other > valid points too - for example, you can't review the changes to them > properly, because any change to them is far too noisy. That point > doesn't go away by reducing the number of defconfigs. Part of the problem with the defconfigs is that they are auto-generated and contain a lot of useless information. As you point out, diffs on defconfigs tend to result in a lot of noise which makes viewing changes very difficult. 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. 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. Having a better way of generating defconfigs (or however the information is stored) would fix the general problem of diffstat noise when changes are made. ~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