Jeff Bacon wrote: > 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?
It's automatic and easily rebuildable: 7 small package build scripts (for each busybox instance), which call a couple of shell functions to say what apps to exclude/include, and whether to XIP, then call out to a common busybox build script. Which is mostly just a sed on .config for those excludes/includes, make oldconfig, make install. The final rootfs is assembled, as just another package, from those binary packages built earlier. It is very easy to change which apps have their own instances and so on. -- 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
