[BusyBox] Improving Our Development Process

[David Douthitt]

On 24 Jan 2001, at 17:30, Mark Whitley wrote:

> Yes, as I mentioned, the original reason offered for the split was so you
> could suid the network-apps binary (i.e. netkit-tiny), but leave the
> shell-apps binary (i.e. busybox) non-setuid. As Alex mentioned earlier,
> though, this can be done even with the existing, single codebase, just by
> building two seperate binaries with two different Config.h files.

Except that EVERYTHING that the two binaries have in common 
(utility.c?) would be built twice, and I suspect that could be a good 
portion of the system.

[Someone else said...]
> > > Alex (and others before him) futher make a good point that
> > > splitting up the apps would cause some redundancy in shared code
> > > (i.e. utility.c) which could lead to further maintenance burdens
> > > (somebody fixes a bug in busybox utility.c, but doesn't fix it in
> > > netkit-tiny utility.c, etc.).

A library would eliminate this problem - utility.c would be in a 
library, and would be fixed once, and would be included in any 
binary only once.

> This is certainly one approach. The thing I dislike about this approach is
> that it complicates development by adding an additional dependency. It also
> makes debugging a little more involved.

I'm not sure what you mean by "additional dependency" - doesn't 
that happen every time a new app is created?  An additional 
dependency in the Makefile doesn't sound like a big thing.

> > What about tinylogin?
> 
> At this point, tinylogin is essentially a "finished" product and consumes very
> little of Erik's (or my, or anybody else's) time.

Reason I mentioned it is it would also be a prime candidate for a 
suid / non-suid split and a library to go with it.

> It could, but the question then becomes: Who becomes the
> maintainer of said library? 

Who becomes the maintainer of anything?  Choosing a maintainer 
shouldn't be a deciding factor to accept or deny.

> What will be the process of moving common code from codebase X, Y,
> or Z into the library. 

Same as most open source projects - things get put in when 
project admin says so.

> If you'd like to make the case for the library (spell out hte list
> of advantages), please do, but personally I don't know if it would
> be an overall win. I can be persuaded otherwise, but right now I'm
> leaning away from the library approach. 

1. Size
2. Lack of replication.

Another thing with this split / non-split in mind: a lib-busybox.a 
would make most all of the arguments between a split and a non-
split moot, since all of the common functions would be debugged 
once and for all each time.

Also, once the library is made and complete, most programming 
will not be done in the library, but in the functions that call the 
library from other code.

How big are the "common" functions?  In my system the busybox 
binary is 150K.... are the common functions 20K?  Imagine a 
busybox/tinylogin combination with suid/non-suid splits:

1. tinylogin (suid) - 20k common
2. tinylogin (nonsuid) - 20k common
3. busybox (suid) - 20k common
4. busybox (nonsuid) - 20k common

This leads to 80k duplicated (if you use the same code between 
tinylogin and busybox) or 40k if you consider tinylogin / busybox 
separate.

-- 
David Douthitt
UNIX Systems Administrator
HP-UX, Linux, Unixware
n9ubh at callsign.net