Jeff Bacon wrote:
> On 4/21/2010 11:04 AM, Lennart Sorensen wrote:
> What version of Busybox are you using? I am finding it difficult to make
> a newer version (1.15.x, 1.16.0) that small. In fact, when I configure
> it with a single applet, I still somehow get a ~200kB binary. Are there
> other options you are using in the build process to make your BB binary
> so small?

You don't have to have just one busybox binary containing everything.

On my 32MB ARM7-ish system, I have init, telnetd and udhdpc each in
separate one-program busybox executables, compiled non-XIP.

Those are individual because they are each long-running programs.
They are not XIP because there is only one instance, so XIP overhead
isn't justified.

Then I have a busybox containing exactly these: test, true, false and
msh.  Those are compiled XIP because there are many instances of them
at once.

Those are the shell, because it is instantiated many times so I want
it to have as little extra stuff as possible.  test, true, false are
forced on by Busybox when msh is enabled, that's why they are included.

Then I have awk, fdisk and login individually, because those are quite
large, or in the case of login, a large data segment (due to password
encryption tables).  Those are all non-XIP, because I don't use them
much. Taking them out of the "big" Busybox makes it quite a lot
smaller.  Reducing data segment size from the big Busybox is more
valuable than reducing code size.

Then I have all the rest of the enabled Busybox programs in a single
executable, compiled with XIP so that multiple instances share code.

All of them are linked statically with uClibc.  Mainly because shared
libs are difficult without FD-PIC, but also it probably makes the data
segment smaller than if there was one large shared uClibc.  But on the
other hand, larger code size and in larger chunks per program, so more
sensitive to fragmentation.  Pros and cons.

The above was done because, despite having 32MB to play with, and
about 10MB free most of the time, when I had one big Busybox and
non-XIP, the system could easily get into a state where allocating
256kB to launch telnetd or a shell from telnetd wasn't possible, so
even remote logging in and rebooting my device wasn't possible.

-- Jamie
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to