you need to do:
-Checkout the Latest Code from CVS
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Checkout the Latest Code
+~~~~~~~~~~~~~~~~~~~~~~~~
This is a necessary first step. Please do not try to work with the last
released version, as there is a good chance that somebody has already fixed
the bug you found. Somebody might have even added the feature you had in mind.
Don't make your work obsolete before you start!
-For information on how to check out Busybox from CVS, please look at the
+For information on how to check out Busybox development tree, please look at the
following links:
- http://busybox.net/cvs_anon.html
- http://busybox.net/cvs_howto.html
+ http://busybox.net/source.html
Read the Mailing List
------------------------
Busybox can always use improvement! If you're looking for ways to help, there
-there are a variety of areas where you could help.
+are a variety of areas where you could help.
What Busybox Doesn't Need
we do not want to start adding mkfs/fsck tools for every (or any)
filesystem under the sun. (fsck_minix.c and mkfs_minix.c are living on
borrowed time.) There are far too many of these tools out there. Use
- the upstream version. Not everything has to be part of Busybox.
-
- - Any partitioning tools: Partitioning a device is typically done once and
- only once, and tools which do this generally do not need to reside on the
- target device (esp a flash device). If you need a partitioning tool, grab
- one (such as fdisk, sfdisk, or cfdisk from util-linux) and use that, but
- don't try to merge it into busybox. These are nasty and complex and we
- don't want to maintain them.
+ the upstream version. Rationale: bugs in these tools can destroy
+ vast amounts of data. Keeping up with filesystem format development
+ is impractical (especially in the area of keeping fsck tool safe
+ and up-to-date).
- Any disk, device, or media-specific tools: Use the -utils or -tools package
that was designed for your device; don't try to shoehorn them into Busybox.
independent. Do not send us tools that cannot be used across multiple
platforms / arches.
- - Any daemons that are not essential to basic system operation. To date, only
- syslogd and klogd meet this requirement. We do not need a web server, an
- ftp daemon, a dhcp server, a mail transport agent or a dns resolver. If you
- need one of those, you are welcome to ask the folks on the mailing list for
- recommendations, but please don't bloat up Busybox with any of these.
-
Bug Reporting
~~~~~~~~~~~~~
If you find bugs, please submit a detailed bug report to the busybox mailing
list at busybox@busybox.net. A well-written bug report should include a
transcript of a shell session that demonstrates the bad behavior and enables
-anyone else to duplicate the bug on their own machine. The following is such
+anyone else to duplicate the bug on their own machine. The following is such
an example:
To: busybox@busybox.net
But when I use BusyBox date I get this instead:
$ date
- llegal instruction
+ Illegal instruction
- I am using Debian unstable, kernel version 2.4.19-rmk1 on an Netwinder,
- and the latest uClibc from CVS. Thanks for the wonderful program!
+ I am using Debian unstable, kernel version 2.4.19-rmk1 on an Netwinder,
+ and the latest uClibc from CVS.
-Diligent
For a quick listing of "needs work" spots in the sources, cd into the Busybox
directory and run the following:
- for i in TODO FIXME XXX; do grep $i *.[ch]; done
+ for i in TODO FIXME XXX; do find -name '*.[ch]'|xargs grep $i; done
This will show all of the trouble spots or 'questionable' code. Pick a spot,
any spot, these are all invitations for you to contribute.
These are dirty jobs, but somebody's gotta do 'em.
- - Converting applets to use getopt() for option processing. Type 'grep -L
- getopt *.c' to get a listing of the applets that currently don't use
- getopt. If a .c file processes no options, it should have a line that
- reads: /* no options, no getopt */ somewhere in the file.
-
- - Replace any "naked" calls to malloc, calloc, realloc, str[n]dup, fopen with
- the x* equivalents found in utility.c.
-
- Security audits:
- http://www.securityfocus.com/frames/?content=/forums/secprog/secure-programming.html
+ http://www.securityfocus.com/popups/forums/secprog/intro.shtml
- Synthetic code removal: http://www.perl.com/pub/2000/06/commify.html - This
is very Perl-specific, but the advice given in here applies equally well to
C.
- - C library funciton use audits: Verifying that functions are being used
+ - C library function use audits: Verifying that functions are being used
properly (called with the right args), replacing unsafe library functions
with safer versions, making sure return codes are being checked, etc.
- "Ten Commandments" compliance: (this is a "maybe", certainly not as
important as any of the previous items.)
- http://web.onetelnet.ch/~twolf/tw/c/ten_commandments.html
+ http://www.lysator.liu.se/c/ten-commandments.html
Other useful links:
changes directly to CVS. This is nice because you don't have to wait for
someone else to commit your change for you, you can just do it yourself.
-But note that this is a priviledge that comes with some responsibilities. You
+But note that this is a privilege that comes with some responsibilities. You
should test your changes before you commit them. You should also talk to an
applet maintainer before you make any kind of sweeping changes to somebody
else's code. Big changes should still go to the mailing list first. Remember,