Toybox design decisions.

Rob Landley rob at
Fri Jan 1 00:13:08 UTC 2010

The main reason I haven't come back to poke at busybox much is I spent a 
couple years doing toybox, and made some very different design decisions in 
that project.  When I come back to busybox, I tend to miss the infrastructure 
I had over there.

Moving any parts of busybox over to the toybox way of doing things would be a 
largeish undertaking (most of it involving documenting the way I did stuff and 
what the advantages are, and hopefully convincing people it's a good idea.)

I dunno if the busybox community would consider the toybox way of things 
"better", especially since it's not what you're used to.  But I thought I'd 
explain some of the stuff I miss about the other project when I look at 

One small and relatively self-contained difference is in the --install 

The busybox binary makes links when it does --install, and has the -s option 
to select symlinks instead of hard links.

The toybox approach is simpler: when you run "./toybox" without arguments, it 
dumps the command names it knows how to do, ala:

  $ ./toybox
  basename bzcat cat catv chroot chvt cksum count cp df dirname dmesg 
  echo false help mdev mkfifo mkswap nc netcat oneit patch pwd rmdir 
  seq sh sha1sum sleep sort sync tee touch toysh true tty uname useradd 
  wget which yes

It lists them in an unadorned manner, suitable for use via "for i in 
$(./toybox); do ln -s toybox /bin/$i; done".  Then whether you choose to 
symlink or to hardlink them is your problem.  There's no other usage message, 
on the theory that anybody dealing with an embedded toybox system either knows 
what to expect or can google it.

(This is "the unix way to do it", by the way.  There's a reason that "ls" just 
dumps a list of files suitable for piping into another program, and leaves a 
more human readable "ls -l" as an option.  Under dos, the "dir" command always 
spits out lots of extraneous information you have to filter _out_ just to get a 
simple file list.  In this instance, busybox is acting like dos "dir", and 
toybox is acting like unix "ls".)

You can also go:

  ./toybox --long
  bin/basename usr/bin/bzcat bin/cat usr/bin/catv usr/sbin/chroot
  usr/sbin/chvt bin/cksum usr/bin/count bin/cp usr/sbin/df bin/dirname
  bin/dmesg bin/echo bin/false bin/help usr/bin/mdev bin/mkfifo sbin/mkswap
  bin/nc bin/netcat sbin/oneit usr/bin/patch bin/pwd bin/rmdir usr/bin/seq
  bin/sh usr/bin/sha1sum bin/sleep usr/bin/sort bin/sync bin/tee bin/touch
  bin/toysh bin/true bin/tty bin/uname usr/sbin/useradd usr/bin/wget
  usr/bin/which usr/bin/yes 

The usage of which is hopefully obvious, and again easy to stick into a 
trivial shell script. :)  (I note that I was lazy, any first argument starting 
with a dash will give you expected install paths, I didn't specifically look 
for "--long" and thus saved maybe a dozen bytes.)

I also have a "toybox help" command:

  $ ./toybox help
  usage: help [command]

  Show usage information for toybox commands.

  help: Needs 1 argument
  $ ./toybox help cp
  usage: cp -fiprdal SOURCE... DEST

  Copy files from SOURCE to DEST.  If more than one SOURCE, DEST must
  be a directory.

  -f      force copy by deleting destination file
  -i      interactive, prompt before overwriting existing DEST
  -p      preserve timestamps, ownership, and permissions
  -r      recurse into subdirectories (DEST must be a directory)
  -d      don't dereference symlinks
  -a      same as -dpr
  -l      hard link instead of copying
  -v      verbose

Which is roughly equivalent to what "busybox --help" does except it gives me 
the shell "help" builtin for free. :) 

Putting all that together, I didn't need to write an equivalent of 
applets/usage_pod.c, I could glue the existing toybox bits together with a 
small shell script.  I taught my make script not to make the help files when 
the help config entry was disabled.  (Also, my standalone applets were a 
separate built invocation, not an autodetected thing that singificantly changed 
the user interface automagically, so I didn't have to worry about that 

Latency is more important than throughput. It's that simple. - Linus Torvalds

More information about the busybox mailing list