On 4/21/2010 11:57 AM, Jamie Lokier wrote: > 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 >
Do you have this set up automatically when building your system, or is a one-time, manually intensive, build process which you then set each BB version aside into some pre-compiled binary folder for inclusion into your RFS? -JB _______________________________________________ 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
