In-Tree vs Out-of-Tree Driver: Where Your Code Should Live

For hardware that your company owns and intends to ship for years, it is recommended to default to putting the driver in mainline and only carrying over the parts that still need work. However, you should keep the driver out of mainline if the hardware is not public, the programming interface is still evolving, or the code cannot be licensed under the GPL.

Choosing between an in-tree or out-of-tree driver impacts maintenance costs and the time required for kernel rebase. The decision can be made by default once the driver is functional and the schedule requires an answer on shipping.

The process for in-tree and out-of-tree drivers is similar, as both produce a .ko file that loads and works. Initially, all modules are developed and built out-of-tree. The method of building either is supported by Kbuild, and all drivers start outside the tree.

Several factors influence the decision between in-tree and out-of-tree drivers. These include the kernel being shipped, product lifecycle, licensing requirements, and the ability to control the driver's changes. If your company supplies a heavily modified kernel, upstreaming may not be helpful for the current product. Devices that ship once have different economics compared to those receiving long-term updates.

In-tree drivers publish information about your hardware, including a binding, while out-of-tree drivers do not. GPL-compatibility is another consideration, as mainline requires GPL-compatible code, and many kernel symbols are exported with EXPORT_SYMBOL_GPL, which non-GPL modules cannot use.

Option A, keeping the driver out of mainline, offers control over the driver's development and allows you to hold back details of unreleased hardware. However, this option incurs costs during the build process, as the kernel does not guarantee an internal interface. Maintaining the driver becomes your responsibility, and bug reports from tainted kernels may be ignored by developers. External modules install under a separate directory (/lib/modules/$(KERNELRELEASE)/updates/) rather than within the kernel directory itself.

Option B, putting the driver in mainline, involves submitting the driver to the subsystem mailing list, providing a device tree binding, and iterating through review until it is merged. The main benefit of this approach is that maintenance shifts away from your team. When a subsystem undergoes changes, the person making the updates will adjust your call sites, as the code must keep building.

The advantages of this method include no O taint, other developers adding features or fixing bugs, and the driver being included in every distribution. Review can be seen as undervalued, as maintainers who have seen numerous bindings often provide better feedback. However, the costs of this approach include review time that cannot be precisely scheduled, the need to describe the hardware publicly, ensuring GPL-compatibility, and maintaining a backport branch until the kernel catches up.

In conclusion, for hardware owned and shipped by your organization over a multi-year life, it is advisable to opt for mainline drivers rather than out-of-tree solutions. By writing against current mainline interfaces from the beginning and submitting the driver promptly, you can minimize the long-term maintenance cost. Treating the out-of-tree period as temporary, with a target kernel release in mind, helps manage expectations.

Failing to make a conscious decision regarding the driver's placement can lead to accumulating local API workarounds, making upstreaming increasingly challenging. Staying out of mainline is appropriate only under specific circumstances, such as unreleased hardware or an NDA preventing the publication of a register description. If the programming interface is still changing frequently or if the code cannot be licensed under the GPL, mainline is the only viable option. Ultimately, the driver becomes single-product glue with no life beyond one board revision.