[BusyBox] Upcoming changes....

Pavel Roskin proski at gnu.org
Fri Jun 30 21:15:16 UTC 2000


Erik,

> > > 1) struct BB_applet in internal.h will be getting a few new members:
> > > 	int min_args;
> > > 	int max_args;
> > 
> > Is it about all arguments or about all non-option arguments? I'm afraid
> > that only few apps will really benefit (i.e. eliminate code) from the
> > former.
> 
> All arguments was what I had in mind.  Right now a lot of apps have code in
> them like:
> 
>         if (argc <= 1)
> 	    usage(tar_usage);

Well, tar is a good example.

[proskin at sunapee busybox]$ ./busybox tar
BusyBox v0.45 (2000.06.30-20:46+0000) multi-call binary -- GPL2
... usage ...
[proskin at sunapee busybox]$ ./busybox tar --exclude foo
Exactly one of 'c', 'x' or 't' must be specified

You see, the first check is optional. Why does "--exclude foo" change the
output? We could leave the second check only. If it fails, tar would print
the help message, maybe with the line about "Exactly one..." attached. As
I already said earlier, I believe that Busybox cannot afford the luxury of
context-sensitive help.

In most cases it is the number of non-option arguments that matters. And
yet that number depends on the switches used. For example, "rm -f" is
valid but "rm -r" is not.

The logic you propose is only good for very primitive apps. Even worse,
some people will expect that the secondary check (after getopt) is not
needed. I don't like a change that will provoke bugs.

> I'm not expecting miracles (things like cat still have to do things
> themselves), but I think this overhead may end up a net win.  It is
> probably worth further research to see if it really is a net win or
> not.

Net win is not the only issue here.

> > > 6) All apps will migrate to using getopt for option parsing.  Those
> > >     that need to handle long options (i.e. tar, rm, ln) will use
> > >     getopt to match "-" and then use strcmps and needed.
> > 
> > Consider GNU getopt. More apps may need it / benefit from it.

I meant getopt_long, sorry.

> Are you talking about getopt_long?  I was just thinking of regular old
> getopt(3).  Long options should be pretty rare in busybox (outside of --help
> and --version).  This will let us optimize for the common case (i.e. short
> options), which as a side effect increases cross-libc portability.  Since the
> few cases with long options can be handled, I think it will be a net win to use
> just getopt.  What do you think?

Please make sure that getopt you are using checks all arguments, supports
"--" and reshuffles argv, otherwise things like "ls --color -l" will
misbehave.

> > It would be nice to rely on the linker, not on defines.
> > I remember me seeing a hack for Linux that eliminated unneeded functions
> > using some features of binutils.
> 
> You mean 
>     CFLAGS += -ffunction-sections -fdata-sections
>     LDFLAGS += --gc-sections
> 
> which only works for static linking.  I spent a few minutes a while
> back trying to get this to do something but I couldn't make it work (I
> have some stuff commented out in the Makefile -- experimenters
> welcome).  The biggest win with this would be making a static
> libbusybox.a out of the common stuff, and staticlly linking busybox
> with it using --gc-sections to trim the cruft.  It would be very nice
> if this let us throw away most of the #defines.

Quoting from "info gcc":

Use this option on systems where the linker can perform optimizations to
improve locality of reference in the instruction space.  HPPA processors
running HP-UX and Sparc processors running Solaris 2 have linkers with
such optimizations.  Other systems using the ELF object format as well as
AIX may have these optimizations in the future.

Not very promising, but still worth trying.

> Hmm.  Unrelated thought:
> 
> I was just thinking that we could make a common function that would set up
> stdin and/or stdout for any app that was interested, so that every app could
> automagicaly be a filter.

I don't understand. You mean support for "-" on the command line?

Pavel






More information about the busybox mailing list