The Problem

While FreeBSD provide ABI backward compatibility in user space, it doesn't provide Kernel ABI backward compatibility, a harder goal to achieve. Package repositories are currently provided for every major FreeBSD release. When a new minor FreeBSD version is released, the previous one is still maintained for 3 months, a time window where two versions of the same major FreeBSD version needs to be supported During this period, the ports are built for the older minor version, because of the backward compatibility guarantee: newer FreeBSD version can still safely use packages built using the previous FreeBSD version. This assumption is not necessarily true for kernel module packages, because the backward compatibility is not guaranteed in kernel space.

The common scenario, especially for laptop users, is a kernel dump after the upgrade, because the graphic kernel modules are provided as packages.

There are several ways to solve this issue, but there is no consensus in the community towards an agreed solution

Many of us agree to focus on RELEASE first and put less focus on STABLE/CURRENT.

Kernel ABI compatibility

This solution means that the kernel ABI is backward compatible.

Kernel module built on installation

In this solution, kernel module packages don't contain binaries, but the code of the module. During installation, the code is compiled on the fly to generate the module using the locally installed kernel headers and toolchain.

Additional idea: a foobar kernel module port could generate 2 packages:

Dedicated kernel module package repository

Because the issue is only affecting kernel modules, one solution is to maintain an additional package repository per minor version of FreeBSD with only kernel modules.

Package repository for minor version

Instead of having one package repository per major version, we could have one package repository per minor version. To avoid additional workload and maintenance burden, the previous package repository could be kept in a frozen state: packages will be available, but not rebuilt/updated. An additional benefit of this solution is that when a new minor release is deployed, it immediately the latest available packages (built using the new toolchain contained in the new minor release), without surprises 3 months later, when the older minor release is discontinued. This solution implies a change on the package repository life cycle.

Additional Note: For the older FreeBSD release, we could only keep quarterly. Security patches will be still propagated and there would be less storage pressure (only one latest)

Other additional considerations

From Warner:

If we have separate repos, we'll need the ability to warn / error-out if the minimum / maximum release constraints are violated. I got a request from the QEMU folks to have the new 13.1 packages fail to install on 13.0 (or have a mode where they'd fail), and that seems like it could be used for the proposed binary repos targeting a specific release as well.

KernelModulePackages (last edited 2022-09-21T12:44:20+0000 by LucaPizzamiglio)