So you want to contribute something to FreeBSD? That is great!
We can always use the help, and FreeBSD is one of those systems
that relies on the contributions of its user base in order
to survive. Your contributions are not only appreciated, they are
vital to FreeBSD's continued growth!
Contrary to what some people might also have you believe, you do not
need to be a hot-shot programmer or a close personal friend of the
FreeBSD core team in order to have your contributions accepted. The
FreeBSD Project's development is done by a large and growing number of
international contributors whose ages and areas of technical expertise
vary greatly, and there is always more work to be done than there are
people available to do it.
Since the FreeBSD project is responsible for an entire operating
system environment (and its installation) rather than just a kernel or
a few scattered utilities, our "TODO" list also spans a very wide
range of tasks, from documentation, beta testing and presentation to
highly specialized types of kernel development. No matter what your
skill level, there is almost certainly something you can do to help the
project!
Commercial entities engaged in FreeBSD-related enterprises are
also encouraged to contact us. Need a special extension to make your
product work? You will find us receptive to your requests, given that
they are not too outlandish. Working on a value-added product? Please
let us know! We may be able to work cooperatively on some aspect of
it. The free software world is challenging a lot of existing
assumptions about how software is developed, sold, and maintained
throughout its life cycle, and we urge you to at least give it a
second look.
What Is Needed
The following list of tasks and sub-projects represents something
of an amalgam of the various core team TODO lists and user requests
we have collected over the last couple of months. Where possible, tasks
have been ranked by degree of urgency. If you are interested in
working on one of the tasks you see here, send mail to the coordinator
listed by clicking on their names. If no coordinator has been
appointed, maybe you would like to volunteer?
High priority tasks
The following tasks are considered to be urgent, usually because
they represent something that is badly broken or sorely needed:
3-stage boot issues. Overall coordination:
&a.hackers
Do WinNT compatible drive tagging so that the 3rd stage can
provide an accurate mapping of BIOS geometries for disks.
Filesystem problems. Overall coordination:
&a.fs
Clean up and document the nullfs filesystem code. Coordinator: &a.eivind
Fix the union file system. Coordinator: &a.dg
Implement Int13 vm86 disk driver. Coordinator: &a.hackers
New bus architecture. Overall coordination:
&a.newbus
Port existing ISA drivers to new architecture.
Move all interrupt-management code to appropriate parts of the
bus drivers.
Port PCI subsystem to new architecture. Coordinator: &a.dfr
Figure out the right way to handle removable devices and then
use that as a substrate on which PC-Card and CardBus support can be
implemented.
Resolve the probe/attach priority issue once and for all.
Move any remaining buses over to the new architecture.
Kernel issues. Overall coordination:
&a.hackers
Fix the syscons ALT-Fn/vt switching hangs. Coordinator: &a.sos
Add more pro-active security infrastructure. Overall
coordination: &a.security
Build something like Tripwire(TM) into the kernel, with a remote
and local part. There are a number of cryptographic issues to getting
this right; contact the coordinator for details. Coordinator: &a.eivind
Make the entire kernel use suser() instead of comparing to 0.
It is presently using about half of each. Coordinator: &a.eivind
Split securelevels into different parts, to allow an
administrator to throw away those privileges he can throw away.
Setting the overall securelevel needs to have the same effect as now,
obviously. Coordinator: &a.eivind
Make it possible to upload a list of 'allowed programs' to BPF,
and then block BPF from accepting other programs. This would allow
BPF to be use e.g. for DHCP, without allowing an attacker to start
snooping the local network.
Update the security checker script. We should at least grab all
the checks from the other BSD derivates, and add checks that a system
with securelevel increased also have reasonable flags on the relevant
parts. Coordinator: &a.eivind
Add authorization infrastructure to the kernel, to allow
different authorization policies. Part of this could be done by
modifying 'suser()'. Coordinator: &a.eivind
Add code to the NFS layer so you cannot chdir("..") out of a NFS
partition. E.g.: /usr is a UFS partition with /usr/src NFS exported.
Now it is possible to use the NFS file handle for /usr/src to get access
to /usr.
Medium priority tasks
The following tasks need to be done, but not with any particular
urgency:
Full KLD based driver support/Configuration Manager.
Write a configuration manager (in the 3rd stage boot?) that probes
your hardware in a sane manner, keeps only the KLDs required for
your hardware, etc.
PCMCIA/PCCARD. Coordinators: &a.msmith and &a.phk
Documentation!
Reliable operation of the pcic driver (needs testing).
Recognizer and handler for sio.c (mostly done).
Recognizer and handler for ed.c (mostly done).
Recognizer and handler for ep.c (mostly done).
User-mode recognizer and handler (partially done).
Advanced Power Management. Coordinators: &a.msmith and &a.phk
APM sub-driver (mostly done).
IDE/ATA disk sub-driver (partially done).
syscons/pcvt sub-driver.
Integration with the PCMCIA/PCCARD drivers (suspend/resume).
Low priority tasks
The following tasks are purely cosmetic or represent such an
investment of work that it is not likely that anyone will get them done
anytime soon:
The first N items are from Terry Lambert <terry@lambert.org>
NetWare Server (protected mode ODI driver) loader and subservices
to allow the use of ODI card drivers supplied with network cards.
The same thing for NDIS drivers and NetWare SCSI drivers.
An "upgrade system" option that works on Linux boxes instead
of just previous rev FreeBSD boxes.
Symmetric Multiprocessing with kernel preemption (requires kernel
preemption).
A concerted effort at support for portable computers. This is
somewhat handled by changing PCMCIA bridging rules and power
management event handling. But there are things like detecting
internal vs. external display and picking a different screen
resolution based on that fact, not spinning down the disk if
the machine is in dock, and allowing dock-based cards to disappear
without affecting the machines ability to boot (same issue for
PCMCIA).
Smaller tasks
Most of the tasks listed in the previous sections require either a
considerable investment of time or an in-depth knowledge of the FreeBSD
kernel (or both). However, there are also many useful tasks which are
suitable for "weekend hackers", or people without programming
skills.
If you run FreeBSD-current and have a good Internet connection,
there is a machine current.freebsd.org which builds a full release
once a day - every now and again, try and install the latest release
from it and report any failures in the process.
Read the freebsd-bugs mailing list. There might be a problem
you can comment constructively on or with patches you can test. Or
you could even try to fix one of the problems yourself.
Read through the FAQ and Handbook periodically. If anything is
badly explained, out of date or even just completely wrong, let us
know. Even better, send us a fix (SGML is not difficult to learn, but
there is no objection to ASCII submissions).
Help translate FreeBSD documentation into your native language (if
not already available) - just send an email to &a.doc asking if anyone is
working on it. Note that you are not committing yourself to translating
every single FreeBSD document by doing this - in fact, the documentation
most in need of translation is the installation instructions.
Read the freebsd-questions mailing list and &ng.misc
occasionally (or even regularly). It can be very satisfying to share
your expertise and help people solve their problems; sometimes you may
even learn something new yourself! These forums can also be a source
of ideas for things to work on.
If you know of any bugfixes which have been successfully applied
to -current but have not been merged into -stable after a decent
interval (normally a couple of weeks), send the committer a polite
reminder.
Move contributed software to src/contrib in the source tree.
Make sure code in src/contrib is up to date.
Look for year 2000 bugs (and fix any you find!)
Build the source tree (or just part of it) with extra warnings
enabled and clean up the warnings.
Fix warnings for ports which do deprecated things like using
gets() or including malloc.h.
If you have contributed any ports, send your patches back to the
original author (this will make your life easier when they bring out
the next version)
Suggest further tasks for this list!
How to Contribute
Contributions to the system generally fall into one or more of
the following 6 categories:
Bug reports and general commentary
An idea or suggestion of general technical interest
should be mailed to the &a.hackers;. Likewise, people with an
interest in such things (and a tolerance for a high
volume of mail!) may subscribe to the hackers mailing list by
sending mail to &a.majordomo;. See
for more information about this and other mailing lists.
If you find a bug or are submitting a specific change, please report
it using the send-pr(1) program or its
.
Try to fill-in each field of the bug report. Unless they exceed
65KB, include any patches directly in the report. Consider compressing
them and using uuencode(1) if they exceed 20KB. Upload very
large submissions to .
After filing a report, you should receive confirmation along with
a tracking number. Keep this tracking number so that you can
update us with details about the problem by sending mail to
. Use the number as the
message subject, e.g. "Re: kern/3377". Additional
information for any bug report should be submitted this way.
If you do not receive confirmation in a timely fashion (3 days to
a week, depending on your email connection) or are, for some
reason, unable to use the send-pr(1) command,
then you may ask someone to file it for you by sending mail
to the &a.bugs;.
Changes to the documentation
Changes to the documentation are overseen by the &a.doc;.
Send submissions and changes (even small ones are welcome!)
using send-pr as described in
.
Changes to existing source code
An addition or change to the existing source code is a somewhat trickier
affair and depends a lot on how far out of date you are with the current
state of the core FreeBSD development. There is a special on-going release
of FreeBSD known as ``FreeBSD-current'' which is made available in
a variety of ways for the convenience of developers working
actively on the system. See for more information about getting and using
FreeBSD-current.
Working from older sources unfortunately means that your changes may
sometimes be too obsolete or too divergent for easy re-integration into
FreeBSD. Chances of this can be minimized somewhat by subscribing to the
&a.announce and the &a.current lists, where discussions
on the current state of the system take place.
Assuming that you can manage to secure fairly up-to-date sources to base
your changes on, the next step is to produce a set of diffs to send to the
FreeBSD maintainers. This is done with the diff(1) command,
with the `context diff' form being preferred. For example:
diff -c oldfile newfile
or
diff -c -r olddir newdir
would generate such a set of context diffs for the given source file
or directory hierarchy. See the man page for diff(1) for more
details.
Once you have a set of diffs (which you may test with the
patch(1) command), you should submit them for inclusion
with FreeBSD. Use the send-pr(1) program as described in
.
Do not just send the diffs to the &a.hackers; or they will get
lost! We greatly appreciate your submission (this is a volunteer
project!); because we are busy, we may not be able to address it
immediately, but it will remain in the pr database until we do.
If you feel it appropriate (e.g. you have added, deleted, or
renamed files), bundle your changes into a tar file
and run the uuencode(1) program on it. Shar archives are
also welcome.
If your change is of a potentially sensitive nature, e.g.
you are unsure of copyright issues governing its further distribution
or you are simply not ready to release it without a tighter review first,
then you should send it to &a.core; directly rather than submitting
it with send-pr(1). The core mailing list
reaches a much smaller group of people who do much of the
day-to-day work on FreeBSD. Note that this group is also
very busy and so you should only send mail to them
where it is truly necessary.
Please refer to man 9 intro and man 9 style
for some information on coding style. We would appreciate
it if you were at least aware of this information before
submitting code.
New code or major value-added packages
In the rare case of a significant contribution of a large body
work, or the addition of an important new feature to FreeBSD,
it becomes almost always necessary to either send changes as
uuencode'd tar files or upload them to our ftp site .
When working with large amounts of code, the touchy subject of
copyrights also invariably comes up. Acceptable copyrights
for code included in FreeBSD are:
The BSD copyright. This copyright is most preferred
due to its ``no strings attached'' nature and general
attractiveness to commercial enterprises. Far from
discouraging such commercial use, the FreeBSD Project
actively encourages such participation by commercial interests
who might eventually be inclined to invest something of their own
into FreeBSD.
The GNU Public License, or ``GPL''. This license is not quite
as popular with us due to the amount of extra effort demanded
of anyone using the code for commercial purposes, but given
the sheer quantity of GPL'd code we currently require (compiler,
assembler, text formatter, etc) it would be silly to refuse
additional contributions under this license. Code under the GPL
also goes into a different part of the tree, that being
/sys/gnu or /usr/src/gnu, and is therefore
easily identifiable to anyone for whom the GPL presents a problem.
Contributions coming under any other type of copyright must be
carefully reviewed before their inclusion into FreeBSD will
be considered. Contributions for which particularly restrictive
commercial copyrights apply are generally rejected, though the
authors are always encouraged to make such changes available
through their own channels.
To place a ``BSD-style'' copyright on your work, include the following
text at the very beginning of every source code file you wish
to protect, replacing the text between the `%%' with
the appropriate information.
Copyright (c) %%proper_years_here%%
%%your_name_here%%, %%your_state%% %%your_zip%%. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer as
the first lines of this file unmodified.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY %%your_name_here%% ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL %%your_name_here%% BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
$Id$
For your convenience, a copy of this text can be found in
/usr/share/examples/etc/bsd-style-copyright.
Money, Hardware or Internet access
We are always very happy to accept donations to further the cause of
the FreeBSD Project and, in a volunteer effort like ours, a little can go
a long way! Donations of hardware are also very important to expanding
our list of supported peripherals since we generally lack the funds to
buy such items ourselves.
Donating funds
While the FreeBSD Project is not a 501(c)(3) (charitable) corporation and
hence cannot offer special tax incentives for any donations made, any such
donations will be gratefully accepted on behalf of the project by
FreeBSD, Inc.
FreeBSD, Inc. was founded in early 1995 by &a.jkh and &a.dg with the
goal of furthering the aims of the FreeBSD Project and giving it a minimal
corporate presence. Any and all funds donated (as well as any profits
that may eventually be realized by FreeBSD, Inc.) will be used exclusively
to further the project's goals.
Please make any checks payable to FreeBSD, Inc., sent in care of the
following address:
FreeBSD, Inc.
c/o Jordan Hubbard
4041 Pike Lane, suite #F.
Concord CA, 94520
[currently using the Walnut Creek CDROM address until a PO box can be
opened]
Wire transfers may also be sent directly to:
Bank Of America
Concord Main Office
P.O. Box 37176
San Francisco CA, 94137-5176
Routing #: 121-000-358
Account #: 01411-07441 (FreeBSD, Inc.)
Any correspondence related to donations should be sent to
, either
via email or to the FreeBSD, Inc. postal address given above.
If you do not wish to be listed in our
section, please specify this when making your donation. Thanks!
Donating hardware
Donations of hardware in any of the 3 following categories are also gladly
accepted by the FreeBSD Project:
General purpose hardware such as disk drives, memory or complete
systems should be sent to the FreeBSD, Inc. address listed in the
donating funds section.
Hardware for which ongoing compliance testing is desired.
We are currently trying to put together a testing lab of all components
that FreeBSD supports so that proper regression testing can be done with
each new release. We are still lacking many important pieces (network cards,
motherboards, etc) and if you would like to make such a donation, please contact
&a.dg for information on which items are still required.
Hardware currently unsupported by FreeBSD for which you would like to
see such support added. Please contact the &a.core; before sending
such items as we will need to find a developer willing to take on the task
before we can accept delivery of new hardware.
Donating Internet access
We can always use new mirror sites for FTP, WWW or cvsup.
If you would like to be such a mirror, please contact
for more information.
Donors Gallery
The FreeBSD Project is indebted to the following donors and would
like to publically thank them here!
Contributors to the central server project:
The following individuals and businesses made it possible for
the FreeBSD Project to build a new central server machine to eventually
replace freefall.freebsd.org by donating the following items:
and his employer, , donated a Pentium Pro (P6) 200Mhz CPU
donated a Tyan 1662 motherboard.
of
donated a Kingston ethernet controller. donated an NCR 53C875 SCSI
controller card.
of
donated 128MB of memory, a 4 Gb disk drive
and the case.Direct funding:
The following individuals and businesses have generously contributed
direct funding to the project:
Sean Eric Fagan
Don Scott WildeRobert T. Morris of
of Japan (a portion of the profits from sales of their
various FreeBSD CD-ROMs.
donated a portion of
their profits from Hajimete no FreeBSD
(FreeBSD, Getting started) to the FreeBSD and XFree86
projects. donated a portion of
their profits from several FreeBSD-related books to the
FreeBSD project. has generously donated
significant funding to the FreeBSD project.Hardware contributors:
The following individuals and businesses have generously contributed
hardware for testing and device driver development/support:
Walnut Creek CDROM for providing the Pentium P5-90 and
486/DX2-66 EISA/VL systems that are being used for our development
work, to say nothing of the network access and other donations of
hardware resources.
TRW Financial Systems, Inc. provided 130 PCs, three 68 GB
fileservers, twelve Ethernets, two routers and an ATM
switch for debugging the diskless code.
Dermot McDonnell donated the Toshiba XM3401B CDROM drive
currently used in freefall.
&a.chuck; contributed his floppy tape streamer for experimental
work.
Larry Altneu , and &a.wilko;,
provided Wangtek and Archive QIC-02 tape drives in order to
improve the wt driver.
Ernst Winter contributed a 2.88 MB
floppy drive to the project. This will hopefully increase the
pressure for rewriting the floppy disk driver. ;-)
sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA
SCSI host adapter cards for regression testing of the NCR and AMD
drivers with their cards. They are also to be applauded for making
driver sources for free operating systems available from their
FTP server .
contributed not only a Symbios Sym8751S SCSI card, but also a set
of data books, including one about the forthcoming Sym53c895 chip
with Ultra-2 and LVD support, and the latest programming manual with
information on how to safely use the advanced features of the latest
Symbios SCSI chips. Thanks a lot!
donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver
development.
Special contributors:
has donated almost more than we can say (see the
document for more details).
In particular, we would like to thank them for the original hardware
used for freefall.FreeBSD.ORG, our primary development
machine, and for thud.FreeBSD.ORG, a testing and build box.
We are also indebted to them for funding various contributors over
the years and providing us with unrestricted use of their T1
connection to the Internet.The has been patiently
supporting &a.joerg; who has often preferred FreeBSD work over
paywork, and used to fall back to their (quite expensive) EUnet
Internet connection whenever his private connection became too
slow or flakey to work with it... has contributed their DOS emulator code to the
remaining BSD world, which is used in the dosemu
command.
Core Team Alumnus
The following people were members of the FreeBSD core team during the
period indicated. We thank them for their past efforts in the service
of the FreeBSD project!
This software was originally derived from William
F. Jolitz's 386BSD release 0.1, though almost none of the
original 386BSD specific code remains. This software has
been essentially re-implemented from the 4.4BSD-Lite
release provided by the Computer Science Research Group
(CSRG) at the University of California, Berkeley and
associated academic contributors.
There are also portions of NetBSD and OpenBSD that have been integrated
into FreeBSD as well, and we would therefore like to thank
all the contributors to NetBSD and OpenBSD for their work.
Additional FreeBSD Contributors
(in alphabetical order by first name):
ABURAYA Ryushirou AMAGAI Yoshiji Aaron Bornstein Aaron Smith Achim Patzner Ada T Lim Adam Baran Adam Glass Adam McDougall Ade Barkah Ade Barkah Adrian Colley Adrian Hall Adrian Mariano Adrian Steinmann Adrian T. Filipi-Martin Ajit Thyagarajan Akio Morita Akira SAWADA Akira Watanabe Akito Fujita Alain Kalker Alan Bawden Alan Cox Alec Wolman Aled Morris Alex Alex D. Chen Alex G. Bulushev Alex Le Heux Alex Nash Alexander B. Povolotsky Alexander Leidinger Alexandre Snarskii Alistair G. Crooks Allan Saddi Allen Campbell Amakawa Shuhei Amancio Hasty Amir Farah Amy Baron Anatoly A. Orehovsky Anatoly Vorobey Anders Nordby Anders Thulin Andras Olah Andre Albsmeier Andre Oppermann Andreas Haakh Andreas Kohout Andreas Lohr Andreas Schulz Andreas Wetzel Andreas Wrede Andres Vega Garcia Andrew Atrens Andrew Gillham Andrew Gordon Andrew Herbert Andrew J. Korty Andrew L. Moore Andrew McRae Andrew Stevenson Andrew Timonin Andrew V. Stesin Andrew Webster Andrey Zakhvatov Andy Farkas Andy Valencia Andy Whitcroft Angelo Turetta Anthony C. Chavez Anthony Yee-Hang Chan Anton Berezin Antti Kaipila Are Bryne Ari Suutari Arjan de Vet Arne Henrik Juul Assar Westerlund Atsushi Furuta Atsushi Murai Bakul Shah Barry Bierbauch Barry Lustig Ben Hutchinson Ben Jackson Ben Smithurst Ben Walter Benjamin Lewis Bernd Rosauer Bill Kish Bill Trost Blaz Zupan Bob Van Valzah Bob Willcox Boris Staeblow Boyd R. Faulkner Brad Karp Bradley Dunn Brandon Gillespie &a.wlloyd
Bob Wilcox Boyd Faulkner Brent J. Nordquist Brett Lymn Brett Taylor Brian Campbell Brian Clapper Brian Cully Brian F. Feldman Brian Handy Brian Litzinger Brian McGovern Brian Moore Brian R. Haug Brian Somers Brian Tao Brion Moss Bruce A. Mah Bruce Albrecht Bruce Gingery Bruce J. Keeler Bruce Murphy Bruce Walter Carey Jones Carl Fongheiser Carl Mascott Casper Castor Fu Cejka Rudolf Chain Lee Charles Hannum Charles Henrich Charles Mott Charles Owens Chet Ramey Chia-liang Kao Chiharu Shibata Chip Norkus Choi Jun Ho Chris Csanady Chris Dabrowski Chris Dillon Chris Piazza Chris Shenton Chris Stenton Chris Timmons Chris Torek Christian Gusenbauer Christian Haury Christian Weisgerber Christoph P. Kukulies Christoph Robitschko Christoph Weber-Fahr Christopher G. Demetriou Christopher T. Johnson Chrisy Luke Chuck Hein Clive LinColman Reilly Conrad Sabatier Coranth Gryphon Cornelis van der Laan Cove Schneider Craig Leres Craig Loomis Craig Metz Craig Spannring Craig Struble Cristian Ferretti Curt Mayer Cy Schubert DI. Christian Gusenbauer Dai Ishijima Damian Hamill Dan Cross Dan Lukes Dan Nelson Dan Walters Daniel Baker Daniel M. Eischen Daniel O'Connor Daniel Poirot Daniel Rock Danny Egen Danny J. Zerkel Darren Reed Dave Adkins Dave Andersen Dave Blizzard Dave Bodenstab Dave Burgess Dave Chapeskie Dave Cornejo Dave Edmondson Dave Glowacki Dave Marquardt Dave Tweten David A. Adkins David A. Bader David Borman