While documenting the source tree layout...

Rob Landley rob at landley.net
Sun Jan 15 19:52:24 UTC 2006


So I'm hanging around the Chicago airport during a 4 hour layover, writing 
documentation (programming.html) and reading the source code.  (I'm trying to 
document the layout of our source tree, and that means I'm looking at the 
layout of our source tree.  A certain amount of head scratching is going on 
here.)

Would someone please explain to me what the following directories are for:

1) debian

No, this isn't deban-utils, this is build scripts, variant configurations, and 
packaging stuff for the use that debian made of busybox about three years 
ago.  I'm all for debian using busybox, but why on earth does the busybox 
tarball contain three year old copies of debian-specific config files?  (Are 
we going to accumulate obsolete versions of config files for Red Hat, puppy 
linux, tomsrtbt, and everybody else who ever used us?)

I say nuke this directory.

2) libpwdgrp

It seems to me that this should either be in loginutils or in libbb.  Why is 
this in its' own directory?  It contains two files, one of which is fairly 
big (25k) but hash_fd in libbb is almost the same size.

I'm happy moving it to either one, but it probably shouldn't stay where it is.

3) patches

Either we apply patches to the tarball or we don't check them in, this strange 
halfway state confuses me.  (I know we've culled this directory down from 
where it was, but we should get rid of what's left of it.)

We should clean it up and nuke it.

4) sysdeps

I know we copied our config from the linux kernel, but having TARGET_OS in 
rules.mak and using it the top level Makefile to find Config.in and defconfig 
is kinda silly.  Right now busybox is highly linux-centric and if we decide 
to move away from that we shouldn't do it by adding special cases for other 
operating systems but instead trying to move towards posix and susv3 to 
become more OS agnostic.  (Which I don't really think is that great an idea 
because all sorts of stuff like losetup and fbsetup isn't in any standard I 
can find.  Heck, if somebody can find a standard for _init_ I'd be happy...)  
In any case, gratuitous infrastructure for something we aren't even planning 
to do yet is unnecessary complication and overengineering.

Nuke this directory.  These two files should either live in scripts/config 
along with the rest of the configuration infrastructure, or they should be at 
the top level of the tarball.  (No strong preference either way.)

5) scripts

The name's misleading.  This directory contains two things (scripts/config is 
our copied and modified version of kconfig, and bb_mkdep.c is vodz's 
dependency checker), both of which are configuration and build 
infrastructure.

A nice cleanup would be to move bb_mkdep.c into scripts/config, and then move 
that up one level and essential turn the "scripts" directory into "config".

---------------

That leaves us with seven infrastructure directories (applets, docs, examples, 
include, libbb, scripts/config, and testsuite) and sixteen applet directories 
(archival, console-tools, coreutils, debianutils, e2fsprogs, editors, 
findutils, init, loginutils, miscutils, modutils, networking, procps, shell, 
sysklogd, and util-linux).

One other wild idea would be moving the 16 applet directories under 
"applets" (ala "applets/init/init.c"), since we've developed rather a lot of 
code and grouping it sanely might be nice...

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.



More information about the busybox mailing list