Chapter 5. Source Tree Guidelines and Policies | FreeBSD Documentation Portal
Description: Source Tree Guidelines and Policies
Keywords: Style Guidelines,MAINTAINER,Makefiles,Contributed Software,Shared libraries

# Chapter 5. Source Tree Guidelines and Policies

This chapter documents various guidelines and policies in force for the FreeBSD source tree.

## 5.1. Style Guidelines

Consistent coding style is extremely important, particularly with large projects like FreeBSD. Code should follow the FreeBSD coding styles described in style(9) and style.Makefile(5).

## 5.2. `MAINTAINER` on Makefiles

If a particular portion of the FreeBSD src/ distribution is being maintained by a person or group of persons, this is communicated through an entry in src/MAINTAINERS. Maintainers of ports within the Ports Collection express their maintainership to the world by adding a `MAINTAINER` line to the Makefile of the port in question:

    MAINTAINER= email-addresses

| For other parts of the repository, or for sections not listed as having a maintainer, or when you are unsure who the active maintainer is, try looking at the recent commit history of the relevant parts of the source tree. It is quite often the case that a maintainer is not explicitly named, but the people who are actively working in a part of the source tree for, say, the last couple of years are interested in reviewing changes. Even if this is not specifically mentioned in the documentation or the source itself, asking for a review as a form of courtesy is a very reasonable thing to do.

The role of the maintainer is as follows:

- The maintainer owns and is responsible for that code. This means that he or she is responsible for fixing bugs and answering problem reports pertaining to that piece of the code, and in the case of contributed software, for tracking new versions, as appropriate.

- Changes to directories which have a maintainer defined shall be sent to the maintainer for review before being committed. Only if the maintainer does not respond for an unacceptable period of time, to several emails, will it be acceptable to commit changes without review by the maintainer. However, it is suggested that you try to have the changes reviewed by someone else if at all possible.

- It is of course not acceptable to add a person or group as maintainer unless they agree to assume this duty. On the other hand it does not have to be a committer and it can easily be a group of people.

## 5.3. Contributed Software

Some parts of the FreeBSD distribution consist of software that is actively being maintained outside the FreeBSD project. For historical reasons, we call this contributed software. Some examples are LLVM, zlib(3), and awk(1).

The accepted procedure for managing contributed software involves creating a vendor branch, where the software can be imported cleanly (without modification) and updates can be tracked in a versioned manner. Then, the content of the vendor branch is applied to the source tree, possibly with local modifications. FreeBSD-specific build glue is maintained in the source tree, not in the vendor branch.

Depending on their needs and complexity, individual software projects may deviate from this procedure, at the discretion of the maintainer. The exact steps required to update a particular piece of contributed software should be recorded in a file named `FREEBSD-upgrade`; for example, libarchive’s FREEBSD-upgrade file.

Contributed software is usually placed in the contrib/ subdirectory of the source tree, with some exceptions. Contributed software used only by the kernel lives under sys/contrib/.

| Because it makes it harder to import future versions minor, trivial and/or cosmetic changes are strongly discouraged on files that are still tracking the vendor branch.

### 5.3.1. Vendor Imports

The standard process for managing contributed software and vendor branches is described in detail by the Committer’s Guide.

## 5.4. Encumbered Files

It might occasionally be necessary to include an encumbered file in the FreeBSD source tree. For example, if a device requires a small piece of binary code to be loaded to it before the device will operate, and we do not have the source to that code, then the binary file is said to be encumbered. The following policies apply to including encumbered files in the FreeBSD source tree.

1. Any file which is interpreted or executed by the system CPU(s) and not in source format is encumbered.

2. Any file with a license more restrictive than BSD or GNU is encumbered.

3. A file which contains downloadable binary data for use by the hardware is not encumbered, unless (1) or (2) apply to it.

4. Any encumbered file requires specific approval from the Core Team before it is added to the repository.

5. Encumbered files go in src/contrib or src/sys/contrib.

6. The entire module should be kept together. There is no point in splitting it, unless there is code-sharing with non-encumbered code.

7. In the past binary files were typically uuencoded, and named arch/filename.o.uu. This is no longer necessary, and binary files may be added to the repository unchanged.

8. Kernel files:

   1. Should always be referenced in conf/files.* (for build simplicity).

   2. Should always be in LINT, but the Core Team decides per case if it should be commented out or not. The Core Team can, of course, change their minds later on.

   3. The Release Engineer decides whether or not it goes into the release.

9. User-land files:

   1. The Core team decides if the code should be part of the installed base system.

   2. The Release Engineering decides if it goes into the release.

## 5.5. Shared Libraries

If you are adding shared library support to a port or other piece of software that does not have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software.

For ports:

- Prefer using the number already selected by upstream

- If upstream provides symbol versioning, ensure that we use their script

For the base system:

- Start library version from 1

- It is strongly recommended to add symbol versioning to the new library

- If there is an incompatible change, handle it with symbol versioning, maintaining backward ABI compatibility

- If this is impossible, or the library does not use symbol versioning, bump the library version

- Before even considering bumping library version for symbol-versioned library, consult with Release Engineering team, providing reasons why the change is so important that it should be allowed despite breaking the ABI

For instance, added functions and bugfixes not changing the interfaces are fine, while deleted functions, changed function call syntax, etc. should either provide backward-compat symbols, or will force the major version number to change.

It is the duty of the committer making the change to handle library versioning.

The ELF dynamic linker matches library names literally. There is a popular convention where library version is written in the form `libexample.so.x.y`, where x is the major version, and y is minor. Common practice is to set the library' soname (`DT_SONAME` ELF tag) to `libexample.so.x`, and set up symlinks `libexample.so.x→libexample.so.x.y`, `libexample.so→libexample.so.x` on library installation for the latest minor version y. Then, since the static linker searches for `libexample.so` when the `-lexample` command line option is specified, objects linked with libexample get a dependency on the right library. Almost all popular build systems use this scheme automatically.

Last modified on: May 23, 2025 by Ed Maste

Prev
Home
Next