[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100713070741.GB26442@pengutronix.de>
Date: Tue, 13 Jul 2010 09:07:41 +0200
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Grant Likely <grant.likely@...retlab.ca>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Nicolas Pitre <nico@...xnic.net>,
Daniel Walker <dwalker@...eaurora.org>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Kevin Hilman <khilman@...prootsystems.com>,
linux-arm-msm@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-omap@...r.kernel.org, Eric Miao <eric.miao@...onical.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: ARM defconfig files
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
> <torvalds@...ux-foundation.org> wrote:
> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@...xnic.net> 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/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists