From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from metis.ext.pengutronix.de ([92.198.50.35]:60100 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751322Ab0GMHHx (ORCPT ); Tue, 13 Jul 2010 03:07:53 -0400 Date: Tue, 13 Jul 2010 09:07:41 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Subject: Re: ARM defconfig files Message-ID: <20100713070741.GB26442@pengutronix.de> References: <20100630104043.GG11746@pengutronix.de> <20100712155518.GA24144@pengutronix.de> <20100712173228.GC9897@n2100.arm.linux.org.uk> <20100712185029.GB14425@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: Grant Likely Cc: Linus Torvalds , Nicolas Pitre , Daniel Walker , Russell King - ARM Linux , Kevin Hilman , linux-arm-msm@vger.kernel.org, Linux Kernel Mailing List , linux-omap@vger.kernel.org, Eric Miao , linux-arm-kernel@lists.infradead.org Hi On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > 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. I just restarted my script on the powerpc defconfigs basing on rc5, I assume they complete in a few days time. > Of course, I'm also operating under the assumption that this is a > temporary measure until one of the better solutions is implemented. ack > 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. I don't understand what you mean with unstable here. They are sensible to changed defaults in the Kconfig files which you can consider to be good or bad. And ack, I like the Kconfig approach, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | From mboxrd@z Thu Jan 1 00:00:00 1970 From: u.kleine-koenig@pengutronix.de (Uwe =?iso-8859-1?Q?Kleine-K=F6nig?=) Date: Tue, 13 Jul 2010 09:07:41 +0200 Subject: ARM defconfig files In-Reply-To: References: <20100630104043.GG11746@pengutronix.de> <20100712155518.GA24144@pengutronix.de> <20100712173228.GC9897@n2100.arm.linux.org.uk> <20100712185029.GB14425@pengutronix.de> Message-ID: <20100713070741.GB26442@pengutronix.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote: > 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. I just restarted my script on the powerpc defconfigs basing on rc5, I assume they complete in a few days time. > Of course, I'm also operating under the assumption that this is a > temporary measure until one of the better solutions is implemented. ack > 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. I don't understand what you mean with unstable here. They are sensible to changed defaults in the Kconfig files which you can consider to be good or bad. And ack, I like the Kconfig approach, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |