BB growth and shrinkage; musings

Sat Nov 6 01:58:02 UTC 2010

On Wed, Nov 3, 2010 at 7:58 PM, Cathey, Jim <jcathey at ciena.com> wrote:
>>perfection is achieved not when there's nothing more
>>to add but nothing more to take away...
>
> Linux/BB gets heavier and heavier, and it's not really
> BB's fault.  I blame the tools/environment.  :-)

It does not. Really. See my other mail.

> I did a quick peek, and the old DNIX system I used to
> spend all my time on was pretty lean.  (SVR2 work-alike.)
> Here are some of the /bin entries:
>
>  dr-xr-xr-x   2 jcathey  root        0 Dec 26  1997 .
>  drwxrwxrwx   2 jcathey  root        0 Dec 31  1969 ..
>  -r--r--r--   1 jcathey  root      892 Oct  3  1993 basename
>  -r--r--r--   1 jcathey  root     9560 Mar 31  1994 cat
>  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chany
>  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chgrp
>  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chmod
>  -r--r--r--   1 jcathey  root    13116 Jul  3  1995 chown
>  -r--r--r--   1 jcathey  root     9472 Sep 13  1995 cmp
>  -r--r--r--   1 jcathey  root     8452 Nov  2  1995 cp
>  -r--r--r--   1 jcathey  root    17640 Mar  7  1996 date
>  -r--r--r--   1 jcathey  root    10716 Jun 19  1996 dd
>  -r--r--r--   1 jcathey  root     9584 Nov 19  1993 df
>  -r--r--r--   1 jcathey  root      892 Oct  3  1993 dirname
>  -r--r--r--   1 jcathey  root    14152 Mar  9  1995 du
>  -r--r--r--   1 jcathey  root     6092 Oct  6  1993 env
>  -r--r--r--   1 jcathey  root     6600 Apr 12  1996 hd
>  -r--r--r--   1 jcathey  root     6528 Mar  9  1995 head
>  -r--r--r--   1 jcathey  root     2616 Aug  2  1994 kill
>  -r--r--r--   1 jcathey  root     8452 Nov  2  1995 ln
>  -r--r--r--   1 jcathey  root    30700 Jan  1  1996 ls
>  -r--r--r--   1 jcathey  root     4384 Oct  1  1993 mkdir
>  -r--r--r--   1 jcathey  root     8452 Nov  2  1995 mv
>  -r--r--r--   1 jcathey  root     2664 Apr 13  1994 nice
>  -r--r--r--   1 jcathey  root     1768 Jul  8  1996 nkill
>  -r--r--r--   1 jcathey  root    18908 Mar 23  1996 ps
>  -r--r--r--   1 jcathey  root     6428 Mar  9  1995 pwd
>  -r--r--r--   1 jcathey  root     3460 Mar 19  1996 renice
>  -r--r--r--   1 jcathey  root     6924 Jul  3  1995 rm
>  -r--r--r--   1 jcathey  root     4204 Oct  2  1993 rmdir
>  -r--r--r--   1 jcathey  root      988 Dec  2  1993 sleep
>  -r--r--r--   1 jcathey  root     5040 Apr 20  1994 sum
>  -r--r--r--   1 jcathey  root      788 May 26  1995 sync
>  -r--r--r--   1 jcathey  root     8760 Sep 20  1994 tail
>  -r--r--r--   1 jcathey  root     3856 Jan 26  1995 tee
>  -r--r--r--   1 jcathey  root    11228 Mar  9  1995 time
>  -r--r--r--   1 jcathey  root     6236 Sep  1  1993 tty
>  -r--r--r--   1 jcathey  root     5596 Sep 28  1995 uname
>  -r--r--r--   1 jcathey  root     5040 Apr 20  1994 wc
>
> The hard links (like the cp/ln/mv triad and ch* quartet)
> don't appear right because this was extracted from a CD,
> not a live system.  Likewise the permissions and ownership
> are wrong.
>
> I bring this up because this system was also the target of
> an extensive squeezing effort, but rather than the swiss army
> knife approach of BB I spent effort on eliminating unnecessary
> code.  (There was a lower barrier to entry this way.) Chiefly
> this meant getting rid of printf where it wasn't really necessary.
>
> This system was 68K-based, with a non-shared highly granular
> libc.  (Original Unix in structure, in other words.)  Removing
> printf in this world got rid of the buffered I/O library, and
> the floating point library,

busybox wouldn't use libm if these two options are off:

CONFIG_FEATURE_AWK_LIBM=y
CONFIG_FEATURE_DC_LIBM=y

Getting rid of printf means avoiding bb_error_msg().
Which is everywhere. Currently, even in xmalloc.

> neither of which are of any real
> use for something like sync, say.  What was left was usually
> interestingly small.

Currently, if you limit yourself to these applets only:

CONFIG_BASENAME=y
CONFIG_FALSE=y
CONFIG_TRUE=y
CONFIG_PIPE_PROGRESS=y
CONFIG_VOLUMEID=y
CONFIG_BBCONFIG=y

then bbox wouldn't use printf. This list can be extended,
but it seems like it is not worth it. Very many applets
want at least print error messages:

# ./busybox cp qwe rty
cp: can't stat 'qwe': No such file or directory

and this needs printf machivery.
Open-coding it without printf will quickly make code bigger
and harder to understand.

> (The full development system had less resources than the usual
> embedded 'toaster' now.  My, how things have changed!)

That is one reason why things get bloated: programs
tend to fill all available storage. IIRC it's one of Murphy laws.

> I wonder how a BB would fare against this other approach,
> in that environment.  In this one, too, except that as
> shared glibc is nigh impossible to ditch it really skews things.

Yep, let's see. Your files total to 243284 bytes (counting hardlinks
only once), and have 37 executables.

I built busybox with 34 applets from that list
(I don't know what are chany, hd, and nkill).

Result on x86-32 with uclibc, shared and static:

# ls -l busybox.shared busybox.static
-rwxr-xr-x 1 root root 60624 Nov  6 02:46 busybox.shared
-rwxr-xr-x 1 root root 69560 Nov  6 02:46 busybox.static

# size busybox.shared busybox.static
   text	   data	    bss	    dec	    hex	filename
  55692	   1394	   8416	  65502	   ffde	busybox.shared
  65477	   1574	   8440	  75491	  126e3	busybox.static

config is attached.

-- 
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.bz2
Type: application/x-bzip2
Size: 5276 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20101106/1274e760/attachment.bin>