[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080610083610.GC1987@cs181133002.pp.htv.fi>
Date: Tue, 10 Jun 2008 11:36:10 +0300
From: Adrian Bunk <bunk@...nel.org>
To: Tim Bird <tim.bird@...sony.com>
Cc: Rob Landley <rob@...dley.net>, linux-tiny <Linux-tiny@...enic.com>,
linux-embedded <linux-embedded@...r.kernel.org>,
linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: mainlining min-configs...
On Mon, Jun 09, 2008 at 06:37:29PM -0700, Tim Bird wrote:
> Rob Landley wrote:
> > On Friday 06 June 2008 18:47:47 Tim Bird wrote:
> >> At a minimum, it would be nice to have a few nice examples
> >> of really, really small configs for things like qemus for different
> >> architectures (just to give embedded developers who are working
> >> on size a starting point).
> >
> > That's more or less what I'm trying to do with my Firmware Linux project:
> > creating cross compilers and minimal native build environments for every qemu
> > target.
>
> Any chance of getting your minimal configs from Firmware Linux mainlined?
It could help finding compile errors in some more "exotic" configurations
early (but I'd question whether the Rob's current configs are really
both minimal and typical for embedded usage - e.g the i686 one having
both ext2 and ext3 enabled but no JFFS2; and enabling all IO schedulers
in the kernel as well as ACPI is also not a typical embedded setup).
But if you want to discover size change with minimal configs early you
anyway have to both:
- constantly keep your configs in shape so that they are both minimal
for some set of hardware support and features and
- investigate for any size changes what caused them
(experience has shown that putting information on a webpage doesn't
fix problems - even for compile errors).
You need both, and ideally constantly done by the same person against
Linus' tree, -next and -mm.
Where to get your minimal configs from at the start is just a small
thing at the beginning - don't underestimate the required manual work
that will have to be done each week.
> Does anyone else think this would be valuable? If not in mainline, it
> would be nice to collect them somewhere, to compare what options different
> developers decide turn on or off.
You already have this when you look at e.g. the ARM defconfigs in the
kernel
> -- Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
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