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 Staying current with FreeBSD 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
<announce@freebsd.org> and
<current@freebsd.org> mailing 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
diff -c -r olddir newdir
diff(1) for more
details.
Once you have a set of diffs (which you may test with the
patch(1) command), you should bundle them up in an
email message and send it, along with a brief description of
what the diffs are for, to
<hackers@freebsd.org>
. Someone will very
likely get back in touch with you in 24 hours or less,
assuming of course that your diffs are interesting! :-)
If your changes don't express themselves well as diffs alone
(e.g. you've perhaps added, deleted or renamed files as well)
then you may be better off bundling any new files, diffs and
instructions for deleting/renaming others into a tar
file and running the uuencode(1) program on it before
sending the output of that to
<hackers@freebsd.org>
.
See the man pages on tar(1) and uuencode(1) for more
information on bundling files this way.
If your change is of a potentially sensitive nature, e.g.
you're unsure of copyright issues governing its further distribution
or you're simply not ready to release it without a tighter review first,
then you should send it to
<core@freebsd.org>
rather than
<hackers@freebsd.org>. 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
in cases where mailing to hackers is truly impractical.