Date:	Tue, 10 Jun 2008 22:48:15 -0500
From:	Rob Landley <rob@...dley.net>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Tim Bird <tim.bird@...sony.com>,
	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 Tuesday 10 June 2008 03:36:10 Adrian Bunk wrote:
> 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).

No argument there.  I just offered them as a starting point for supporting 
each qemu target.

I'm emulating a native build environment, meaning I need an emulated hard 
drive with gibabytes of writable space; lots of embedded devices use 
initramfs and nothing else.  I'm using distcc so I need a working network 
card and network stack, which lots of devices won't need.  Also, some of them 
(mips comes to mind) need to be stripped down some more.

(The ext2 plus ext3 thing is because ext2 isn't happy about writable mounts 
where the emulator gets killed out from under it and then needs fsck, but 
ext3 isn't really happy with small read-only mounts ala initrd.  I keep 
meaning to teach ext3 to work without a #*%&# journal, at least on read only 
mounts, but it's about 150 entries down on my todo list...)

I keep meaning to refactor the configs into two files, so "just enough to boot 
this with a serial console" is a separate file from things like filesystems 
and network stack that are common to all of 'em.  (Then concatenate the two 
to get a miniconfig.)  I'm not _quite_ convinced the extra build complexity's 
worth it...

> 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

I find miniconfig helps here.

> - 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.

Speaking from experience, this is a huge #*%&# pain.  (I'm trying to track 
this sort of changes for less than a dozen qemu configs.  There are hundreds 
of defconfigs in the tree, most of which I can't boot test...)

However, qemu can be automated and scripted.  (Especially when /dev/console 
attaches to qemu's stdin and stdout.  That's why I need each platform to know 
how to shut _down_, and exit the emulator.  Currently, powerpc -M prep 
doesn't do this. :P)

> 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.

Eh, I'd suggest every -pre release.

And starting with tracking the size regressions in just _one_ platform is 
probably best.  I'd suggest either x86 (32 bit, matches arm) or x86_64 
(largest userbase at this point, even Via's finally switched over).

> > 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

I've got a script running to convert all the 2.6.25 defconfigs into 
miniconfigs, which I find makes 'em easier to read.  I'll post the results 
when it finishes...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
--
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