Re: 2.6.1-rc1-tiny1 tree for small systems

[ebiederm@xmission.com (Eric W. Biederman)]

Matt Mackall <mpm@selenic.com> writes:

> On Sun, Jan 04, 2004 at 12:42:43AM -0700, Eric W. Biederman wrote:
> > Matt Mackall <mpm@selenic.com> writes:
> > 
> > > Contributions and suggestions are encouraged. In particular, it would
> > > be helpful if people with non-x86 hardware could take a stab at
> > > extending some of the stuff that's currently only been done for X86 to
> > > other architectures.
> > 
> > I just tried a kernel build with as much as possible turned off.  This
> > uncovered a couple of bugs, which I fixed with the attached diff.  But
> > it looks like there finally is a light at the end of the rainbow.
> 
> Thanks. I actually cleaned up all this stuff earlier today, will
> probably do another release shortly.
>  
> > 220K compressed and 371K uncompressed.  This is a serious reduction from
> > previous versions.  There is still a huge amount of code I can't compile
> > out but this is certainly progress.  Thank you.
> 
> Suggestions? I'm rapidly exhausting a lot of the obvious candidates.
> My target build at the moment is ide + ext2 + proc + ipv4 + console, and
> that's currently at around 800K uncompressed, booting in a little less
> than 2.5MB. Hoping to get that under 2.

Nice.  I have a 386 I really should try this out on.

Of note IPv4 is about 90K compressed.  And I know you can do a minimal
IPv4 stack in about 8K compressed.

My target is a minimal kernel that can be used as a bootloader.  But
what I am looking for at first is to be able to turn as many things
off as possible so that we can test to see how much individual pieces
add.

If you look at ELKS or one of the old unix like kernels you can get
those down to 64K and still be usable.

I'm currently looking at removing the buffer cache, since I most
of the time I don't care about disks.  This is complicated by the fact
that many of the default paths in the kernel when they don't have a
better implementation use buffer cache methods.  But I'm making
headway.

Proc is one of things that frequently has loads of crap that are
not needed in a minimal setup.

Until I find more candidates to turn off I can't see any low hanging
fruit for shrinking in size.

Eric