From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@secretlab.ca (Grant Likely) Date: Mon, 12 Jul 2010 13:50:47 -0600 Subject: ARM defconfig files In-Reply-To: References: <20100603181010.GA25779@flint.arm.linux.org.uk> <1275589230.23384.19.camel@c-dwalke-linux.qualcomm.com> <20100614083214.GA2104@pengutronix.de> <20100630104043.GG11746@pengutronix.de> <20100712155518.GA24144@pengutronix.de> <20100712173228.GC9897@n2100.arm.linux.org.uk> <20100712185029.GB14425@pengutronix.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds wrote: > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre wrote: >> I think Uwe could provide his script and add it to the kernel tree. >> Then all architectures could benefit from it. ?Having the defconfig >> files contain only those options which are different from the defaults >> is certainly more readable, even on x86. > > Quite possible. But maintainers would need to be on the lookout of > people actually using the script, and refusing to apply patches that > re-introduce the whole big thing. I can (partially) speak for powerpc. If ARM uses this approach, then I think we can do the same. After the defconfigs are trimmed, I certainly won't pick up any more full defconfigs. Of course, I'm also operating under the assumption that this is a temporary measure until one of the better solutions is implemented. I do suspect that the trimmed defconfigs will tend to be unstable and will still require manual maintenance. I think the Kconfig fragments approach is the most promising if the dependencies issue can be solved. g.