Kernel image size

.6.15

ed

e

nline

om

Not that I can help on this, but I am curious on a related note; what does this kernel do? My DPS (not for the 405, just for 5200B and for the 824x so far) "kernel", dps.syst, contains things up to and including the filesystem - it has to spawn a shell to have command line functionality. dps.syst is 106100 bytes long; shell is apr. 42k. This without windows, graphics and tcp/ip; it takes another apr.

500k to add these. So I am just curious to see what other people do.

Dimiter

P.S. Here is a new product with the mpc5200b, it runs all of the above and some more:

.

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Not sure I understand what you're getting at - re-reading my post I realise that I failed to mention that it was a Linux kernel which was a bit stupid of me!

Anyway, we use Linux on them because it means we can run the same app on small embedded systems up to large fast hardware on a variety of architectures.

I'm just curious as to why it's increased 50% in size from the .15 to the .31 releases and wonder if anyone else has noticed this. Probably not the best group to ask on, but then embedded folk usually care more about size than others.

Nobby

DEBUG build? Not stripped?

A lot has happened between those two:

2.6.15 03-Jan-2006 2.6.15.7 28-Mar-2006 ... 2.6.31 09-Sep-2009 2.6.31.6 10-Nov-2009

Newer kernels occasionally get new features which are enabled by default, and would need to be explicitly disabled.

Individual drivers often have tables of known devices, and workarounds for broken hardware. The size of both tends to increase over time.

Compilation options can make a lot of difference. An kernel built for embedded use probably won't use the default switches.

If you're building these kernels from source, you can examine the number and size of the object files which are built. More files tends to indicate more features (drivers, modules), consistently larger files would indicate compilation switches, inconsistently larger files would indicate specific components acquiring new features.

I _think_ that the (Linux) kernel build, by default, includes drivers for every known device that hes ever been plugged into a Linux machine, including the kitchen sink if it happens to have a USB port (but there's also a driver for kitchen sinks that use legacy parallel ports, and two different flavors of serial).

Cutting all that out should keep the kernel size down.

--
www.wescottdesign.com

Thanks to everybody who replied. I did eventually get the size down to near the old one by severely trimming out lots of options - as Nobody said there are a bunch of new things that are enabled by default. I'm not sure I know what made the biggest difference but the filesystem drivers had a marked effect - I didn't have any filesystems enabled that I don't need, but there seem to be a bunch of new options for the ext2-class of filesystems that make for quite a hefty kernel.

I did find this web page which might be of some use to somebody:

which introduced me to the aptly-named bloat-o-meter in the scripts directory in the kernel sources!

Cheers, Nobby