[BusyBox] Re: What happens with busybox/Makefile?
Erik Andersen
andersen at lineo.com
Wed Jun 7 19:57:35 UTC 2000
On Tue Jun 06, 2000 at 09:08:52PM -0400, Pavel Roskin wrote:
> Hello!
>
> Erik, you mentioned in a private message systems that don't have shared
> libraries. This means that you have libc functions linked to every
> executable. Shouldn't we merge Busybox and Tinylogin then?
I don't think merging them is very good idea, for several reasons. First of
all is security. Sometimes, tinylogin needs to be setuid. We have gone to a
lot of trouble to try and audit the code in tinylogin to catch the most likely
security problems. BusyBox has never had any auditing, so making it setuid
would be a very, very bad idea. This is also why netkit-tiny is going to be
happening -- so that it can be standalone, carefully audited for security, and
can be safely setuid if needed.
Another reason for splitting things into smaller chunks is to reduce memory
usage. As BusyBox adds in more and more stuff, the bss size gets bigger, which
means the minimum amount of memory needed to run any particular app (say 'ls')
gets bigger with more apps. Splitting things into smaller chunks means less
stuff needs to be loaded at any particular time (% demand paging). Of course,
having about 90 standalone apps means that there are about 90 ELF headers, plus
a whole bunch of additional transfer vectors for subroutine linkage between
each executable and each shared library (i.e. if 'cat' calls printf, and 'ls'
also calls printf, and both 'cat' and 'ls' are in the same executable, there
only needs to be one transfer vector for printf, but if they are standalone
apps, each app needs its own), so going with lots of standalone apps on an ELF
system is not a good move either.
For some systems (such as uClinux) the maintainers have their own gcc, their
own hacked up binary format, etc, that essentially eliminates all the reasons
for chunking apps together except for the cost of statically linking -- and for
that they have their own version of libc that is very, very well suited for
static linking (which incidentally, I have begun porting to x86 -- makes a 4k
staticly linked "Hello World" on x86, vs 200k with GNU libc).
Another reason for splitting things is keeping things grouped together by
function, which means there is less junk to sift through when configuring and
installing the app. This also makes it easier to maintain. For example, I
have been toying with the idea of splitting BusyBox into fileutils, shellutils,
etc chunks.
So my take on things is that grouping things into related chunks is good, but
if any chunk gets too big, the liabilities begin to outweigh the advantages. I
think Busybox and Tinylogin should continue to be separate. I think whether
folks want to produce a single binary from BusyBox and friends, or want to
produce lots of tiny binaries, is up to them and I want to accomodate both sets
of needs. It turns out that producing lots of tiny binaries is a very
difficult problem. I can produce standalone binaries easily enough, but making
them optimally small by eliminating the extra junk pulled into utility.c and
the other shared components by the other apps, is hard.
-Erik
--
Erik B. Andersen email: andersen at lineo.com
--This message was written using 73% post-consumer electrons--
More information about the busybox
mailing list