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