[BusyBox] Improving Our Development Process

[Mark Whitley]

On Wed, Jan 24, 2001 at 10:39:18AM -0500, Gennady Feldman wrote:
> On Tue, 23 Jan 2001, Erik Andersen wrote:
> 
> > [clipped]
> > Hmm.  I think this is a good idea and I think we can extend it
> > much further.  I am not very fond of the current state of things
> > where we have 120 something C files in one flat directory.  It
> > would be nicer to split things up into a bunch of logical blocks,
> > i.e.  fileutils, shellutils, etc.
> >
> >  -Erik
> 
> I propose the following directory structure to start from:
> 
>  busybox (main directory containing all the files could be busybox-0.50
>  |        also could be created when extracting tar.gz file)
>  |
>  \ doc   (contains all the documentation files)
>  |
>  \ src   (contains all the source files)
>   |
>   \ busybox  (busybox part of the package)
>       |
>       \ fileutils    (sections added as proposed by Erik)
>       |
>       \ shellutils   (sections added as proposed by Erik)
>   |
>   \ netkit-tiny (netkit-tiny part of the package)
>   |
>   \ others?? tiny-login?

If we're going to do this, I'd like to propose we keep the naming convetion
consistent, i.e.: fileutils/ shellutils/ netutils/ loginutils/ etc.

>  compilation:
>   busybox\Makefile 	would do a make -C <dirname> for all the subdirectories
> 			which would compile/generate all the documentation
> 			and binary files
> 
>   busybox\doc\Makefile	would generate the documentation
> 
>   busybox\src\busybox\Makefile busybox Makefile
> 
>   and so on...

Sounds good.

>  The only confusing thing is how are we going to track the selected
> applets to compile and how many Config.h files will we have?

See my earlier email re: "applet pools" for an answer to this. In a nutshell:

 - One "stock" Config.h file for configuring _all_ applets in _all_ directories.
 - N number of "canned" Config.h files (possibly in a "pools" directory) for
   each of the pools.

>   README, LICENSE and other files go into the root directory. This is
> actually a somewhat standard file/directory layout for many projects.

Agreed. Along these same lines, as long as we're proposing directory
restructuring, I think we should switch to using autoconf as well.

>  The only remaining issues are:
>  - Are we going to start re-organizing the CVS tree to confirm w/ the new
> directory layout (we could also create a new branch and tag the old one
> for reference)

Per Larry Doolittle's email, I think we should finish up the last few bugfixes
and tag/release version 0.49 before we start rearranging things.

>  - should we have MAINTAINERS file w/ lists of who is maintaing what
> file(s) in this subdirectory and where patches should be directed to for
> testing/approval?

I would prefer either of the following two approaches:

	- 1 MAINTAINERS file in the root dir along with README LICENSE, etc.
	- No MAINTAINERS file, but a "Maintainer: name <email>" line in each
	  source file. (this is my favorite)

>  - I can start prototyping or helping out on getting the new directory
> structure in place that is if we decide to go in this direction.

Let's wait until 0.49 is out the door, and let's also give this email
discussion a little longer to "cook".

>  - The issue of selecting which binaries/applets are going to be compiled
> is a complicated one, should we write a program/script something like
> menuconfig in the linux kernel to do binary/applet selection?

Erik also talked about this. If we're going to get that involved (and I
actually don't think we are), I think we should give ESR's CML2 a serious
look. (http://www.tuxedo.org/~esr/kbuild/)

>  - Also on the plus side we could create >2 binaries. For example we could
> split out SH as a separate binary file for the interactive shell. This
> would let us use it in our regular environment, which in turn is going to
> give it sufficient testing and patches/improvements. Since it's a separate
> entity and a rather complicated one we could just let it be compiled
> either separately or into the main busybox executable.
> 
> P.S. What do you guys/gals think about this?

The existing busybox configuration system (i.e. Configure.h) allows people to
compile all applets into one binary, or each applet into its own binary. I
would like very much for this range of granularity to be preserved. The one
thing I would object to, if we split up the code files into subdirectories, is
if no provisions were made for compiling all applets into a single binary
(including all network apps, etc.); the granularity of compilation should be
as coarse or as fine as the individual user wants.

On Wed, Jan 24, 2001 at 08:27:01AM -0800, Matt Kraai wrote:
> On Wed, Jan 24, 2001 at 10:39:18AM -0500, Gennady Feldman wrote:
> > P.S. What do you guys/gals think about this?
> 
> I think this proposal is a much better idea than splitting the
> source across several repositories.

Agreed.

> I'd like to make the follow suggestions:
> 
>  1) There should be two output options -- one which generates two
>     binaries (one suid and the other not) for the paranoid (at the
>     price of duplicated common code), and another which drops
>     permissions for non-suid processes.

Once again, see my previous email re "applet pools".

Also, I think Vladamir's suid-wrapper is probably a good solution to this
problem.

>  2) One Config.h file in the root directory which specifies all
>     the applets, rather than splitting them across directories.

Agreed.

>  3) The functions of utility.c should be split into separate files
>     in a libbusybox subdirectory to get rid of the #ifdef X || Y
>     nastiness that is currently there (and often broken).

This is probably the best argument for a libbusybox that I've seen so far.

>  4) While we are at it, reworking the documentation wouldn't be a
>     bad idea either.  

Agreed. I think we should decide, once and for all, on a "core" documentation
format and then use it to generate other formats. Personally, I think
SGML/DocBook is the best route to go.


Mark Whitley
markw at lineo.com