The rebase tax: where a driver lives is a staffing decision, not a packaging one

The mechanism behind the mainline discount is the build system, not collegiality. When a subsystem gets reworked, the developer doing the rework updates your call sites, because the tree has to keep compiling ^[14]. Greg Kroah-Hartman's description of the kernel's internal interface, quoted in the piece, is that function names change, structures grow and shrink, parameters get reworked, and all of the instances of where an interface is used within the kernel are fixed up at the same time ^[9]. A driver in your own repository is not one of those instances, so the fixup lands on your team, every rebase ^[10]. Identical artifact ^[4], different payroll.

The two costs are not the same shape and should not be compared as if they were. Upstream review is paid once, in calendar time you cannot schedule precisely, commonly across several rounds ^[16]. The out-of-tree cost is paid again on every rebase for as long as the product exists ^[3]. One is a project with an end; the other is a subscription ^[19].

Two of the out-of-tree costs are not build-time at all. Loading the module sets taint bit 12, the letter O, and the kernel documentation says bug reports from tainted kernels will often be ignored by developers ^[11]. That means the diagnosis stays in your building whether or not you budgeted for it ^[20]. With CONFIG_MODVERSIONS, a symbol CRC mismatch makes the kernel refuse to load the module ^[12], so the drift you did not catch stops being a compile error during the rebase and becomes a board that comes up without its driver ^[21]. The module also installs under /lib/modules/$(KERNELRELEASE)/updates/ rather than kernel/ ^[13], which is worth knowing before someone goes looking for it in the wrong directory on a customer's machine.

None of this makes out-of-tree wrong, and the honest counterweight is in the same source. If your SoC vendor ships a heavily modified tree, upstreaming does nothing for this year's product ^[6]. Out of tree you decide when the driver changes, review it internally, hold back details of unreleased hardware, update the module independently of the kernel image, and you can work at all in a vendor BSP, a customer's kernel, or a certified build ^[17].

What matters is that the three conditions the author gives for staying out of tree do not have the same durability ^[2]. Unpublished hardware becomes public. A moving programming interface settles. Licence does not resolve itself: mainline requires GPL-compatible code, and many kernel symbols are exported with EXPORT_SYMBOL_GPL, which a non-GPL module cannot touch ^[8]. So two of the three are dated conditions and one is permanent ^[22]. If your reason for staying out is a date that has passed, you are paying the subscription out of habit.

The entry price upstream is not mysterious: the subsystem mailing list, a device tree binding as a YAML schema, a MAINTAINERS entry, review rounds, then a CONFIG_ symbol like any other driver ^[18]. The binding is read by maintainers who have seen several hundred of them, and the result is usually better than what you sent ^[16].