[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