Differences

This shows you the differences between two versions of the page.

--- kernelmodulepackages [2022/09/21 07:53] – LucaPizzamiglio
+++ kernelmodulepackages [2023/10/18 21:04] (current) – Italicise both 'user space' and 'kernel', to help distinguish between the two. GrahamPerrin
@@ Line 1: / Line 1: @@
 ====== The Problem ======
-While %%FreeBSD%% provide ABI backward compatibility in user space, it doesn't provide Kernel ABI backward compatibility, a harder goal to achieve.
+While %%FreeBSD%% provides ABI-backward compatibility in //user space//, it does not 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
+When a new minor %%FreeBSD%% version is released, maintenance of the previous minor version continues for three months — a time window in which two versions of the same major %%FreeBSD%% version need 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.
@@ Line 9: / Line 9: @@
 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
+====== Solutions ======
-===== Kernel ABI compatibility =====
+There are several ways to solve this issue, and two solutions have been identified to fix it.
-This solution means that the kernel ABI is backward compatible.
-Pros: fix the issue at the root. Easy to manage, only kernel developers are involved.
-Cons: Hard to implement. External kernel modules are out of hands, the entire burden is on kernel developers. Moreover, limitations introduced by this guarantee could severely limit the development.
 ===== 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.
-Pros: package is built on the fly, adapting to the local version. Extended support for STABLE.
+  * Pros:
-Cons: first tests shows several corner cases, implicit dependency of kernel header and toolchain (several vendors uses packages without the toolchain), less reproducible.
+    * package is built on the fly, adapting to the local version of %%FreeBSD%%
+    * support for STABLE/CURRENT out of the box
-===== Dedicated kernel module package repository =====
+  * Cons:
-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.
+    * first tests shows several corner cases
-Pros: solve the issue for RELEASE, small overhead on poudriere (only kernel module are built twice)
+    * implicit dependency of kernel header and toolchain (several vendors uses packages without the toolchain)
-Cons: pkg has to be aware of Kernel ABI versioning, needs of additional repositories, changes in the package build process, changes in the default repository configuration
+    * less reproducible builds
+**Additional idea**: a //foobar// kernel module port could generate 2 packages:
+  * ''%%foobar-kmod%%'' (binary package)
+  * ''%%foobar-kmod-src%%'' (source package automatically built on install - the name is up for improvements)
 ===== Package repository for minor version =====
@@ Line 31: / Line 31: @@
 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.
-Pros: solve the issue for RELEASE, small overhead on poudriere (we could keep only quarterly up to date for the older release)
+  * Pros:
-Cons: pkg has to be aware of Kernel ABI versioning, needs of additional storage, changes in the package repository life cycle, possible changes in the default repository configuration
+    * solve the issue for RELEASE
+    * small overhead on poudriere (we could keep only quarterly up to date for the older release)
+  * Cons:
+    * pkg has to be aware of Kernel ABI versioning
+    * additional pressure on repository storage
+    * changes in the package repository life cycle
+    * possible changes in the default repository configuration
+**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%%'')
+====== Others solutions ======
+Those solutions have been evaluated and considered less promising, so they won't be implemented.
+===== Kernel ABI compatibility =====
+This solution means that the kernel ABI is backward compatible.
+  * Pros:
+    * fix the issue at the root
+    * Easy to manage, only kernel developers are involved
+  * Cons:
+    * Hard to implement
+    * External kernel modules are out of control
+    * The entire burden is on kernel developers
+    * Kernel ABI backward compatibility could introduce limitations severely limiting the %%FreeBSD%% development
+===== 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.
+  * Pros:
+    * solve the issue for RELEASE
+    * small overhead on poudriere (only kernel module are built twice)
+    * minimal pressure on mirror storage requirements
+  * Cons:
+    * pkg has to be aware of Kernel ABI versioning
+    * needs of additional repositories
+    * changes in the package build process
+    * changes in the default repository configuration
+==== 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.