[BusyBox] RFC: telnetd/inetd/httpd

Chris Meadors clubneon at hereintown.net
Mon Oct 29 12:13:41 UTC 2001


On Mon, 29 Oct 2001, Stefan Soucek wrote:

> Hmm. Wasn't busybox designed to collect a bunch of small apps to make more
> efficient flash usage when running on systems without an MMU and, thus,
> without shared libs? I agree that putting more apps in the busybox binary
> would make this even more efficient.
>
> But there is a downside, too. Making the busybox binary bigger and bigger
> you run into a problem on MMU-less systems: memory allocation. Since memory
> pages are managed by providing a number of certain sized-blocks, they eat up
> the complete block when you load the busybox binary. In other words, the
> bigger the binary is, the more inefficient DRAM memory usage will get.
>
> Here is an example: Say busybox is 530K. This is just a bit over 512K, so
> the next available memory block size is 1M. This means you'll need 1M each
> time you issue an "ls" or "rm". You may consider this to be a trade-off with
> FLASH efficiency since "ls" runs for a short time and exits again, freeing
> up the 1M RAM block. But things get pretty ugly when running for instance
> inetd. Then you'd need 1M of RAM to just run inetd (a 30-50K binary by
> itself depending on the architecture).
>
> In the end, what will hapen  is that given this very big and functionally
> rich busybox binary, you'll start to break out parts of it and compile them
> stand-alone, to save RAM space. But then you'll end up with the same FLASH
> efficiency factor as before adding inetd, httpd, etc. to busybox.
>
> On a shared lib system, I wouldn't see the obvious advantage to have this
> big busybox binary, either. Even so, you could do without it completely, as
> do common Linux distributions with shared libraries.
>
> Just my humbnle thoughts on the future direction of this project...

I thought that I had seen something on the linux-kernel list about
executing in place.

That way you have BB in a compressed ram-disk image.  When the box boots
is decompresses to a RAM disk.  If this RAM disk can be memory mapped, the
kernel can then just execute the code from there, rather than having to
copy to over to another location in RAM and creating the problem you are
speaking of.

I'm not sure where Linux stands with the execute in place feature now.
But I do remember this discussion and it was aimed toward embeded use.

-Chris
-- 
Two penguins were walking on an iceberg.  The first penguin said to the
second, "you look like you are wearing a tuxedo."  The second penguin
said, "I might be..."                         --David Lynch, Twin Peaks







More information about the busybox mailing list