busybox current status

[Rob Landley]

On Sunday 03 December 2006 4:30 am, Denis Vlasenko wrote:

> > I never actually went back and redid the structure I'd inherited (my goal 
was 
> > minimally intrustive changes), but for toybox I'm writing a new one.
> 
> I'm usually not rewriting stuff from scratch (maybe because I am lazy).

I find writing code easier than reading code.  This is a trap I try not to 
fall into, since often the existing code has been debugged for years and now 
handles all sorts of strange corner cases that are totally undocumented 
anywhere except in the implementation.

Joel Spolsky wrote a couple articles about this:
http://www.joelonsoftware.com/articles/fog0000000069.html
http://www.joelonsoftware.com/articles/fog0000000027.html

Doing a minimally invasive set of changes to sed and preserving as much of the 
existing structure as possible was a learning exercise on my part (and also a 
response to the fact that I didn't have a _clue_ how sed worked, and thus if 
I broke stuff outside of the test cases I was trying to fix, I'd have no way 
of knowing).

That said, once you understand the problem you generally _can_ write a much 
smaller version.  (Joel's deep in the proprietary software tradition, and 
doesn't fully understand either open source or hobbyist programming.)  But 
you can't skip the "understanding the problem" step.  (For example, with 
command shells I've been studying on and off for a year, and consider myself 
about halfway there.)

> Will be happy to see/test/use your new code - it's usually both
> very good and much smaller. Thank you for your work.

You're welcome to it (it's GPLv2), but I don't know how much use it'll be.  
I'm designing toybox around very different principles.

For example, the "union of global structs" thing I mentioned idly here months 
ago is integral to how toybox works: it can't parse command line options 
without it.  There's a global "struct toys toys;" that contains data supplied 
to all commands, and a "toy.command" (ala toy.df or toy.mdev) that's the 
union with data for this particular command.

The command line parsing is integrated into the overall toybox infrastructure, 
so each command's arguments are parsed from toybox_main(), before the 
command_main() gets run.  The getopt-like string telling get_optlfags() how 
to parse the arguments for this command is one of the arguments to the 
NEWTOY() macro in toys/toylist.h, and the data that would have gone into 
varargs in busybox instead goes into the first fiew fields of the 
appropriate "toy" union.

For example, with the "df" command has the following in toys/toylist.h:

  struct df_data {
      struct arg_list *fstype;
      long units;
  };

  USE_DF(NEWTOY(df, "Pkt*a", TOYFLAG_USR|TOYFLAG_SBIN))

Because of that, when df_main() gets run, toys.optflags is already filled out 
based on the flags seen (so "a" sets flag 1, "t" sets flag 2, "k" sets flag 
4, and "p" sets flag 8.  This order makes more sense to me because it's the 
same order boolean digits go in: values are supposed to increase as you go to 
the left.)

The * after t means this takes an argument and it can occur more than once so 
it should be a list, and since that's the first entry returning an argument 
it stores its result in toy.df.fstype.  Note that toy.df.fstype isn't filled 
out by option parsing, so it's initialized to 0.

Remaining arguments are copied into toys.optargs[], and although that array of 
char * is malloced, the strings it points to aren't (they're the raw 
environment data) and shouldn't be freed.  (toys.optargs[] itself is freed by 
the return to toybox_main().)  You can still access the raw unmodified 
argument list through toys.argv[], they're not permuted and parsing them 
shouldn't change what appears in "ps".

That's just one example of the infrastructure being different.  I haven't used 
any code from BusyBox yet, although I'm starting to port over some of the 
applets I wrote.  (Which includes going through the svn history to make sure 
I know where it all came from.  Currently I've just taken stuff I'm the only 
contributor to.)

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery