Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| kernelmodulepackages [2022/09/21 12:44] – 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 ====== | ====== The Problem ====== | ||
| - | While %%FreeBSD%% | + | While %%FreeBSD%% |
| Package repositories are currently provided for every major %%FreeBSD%% release. | Package repositories are currently provided for every major %%FreeBSD%% release. | ||
| - | When a new minor %%FreeBSD%% version is released, the previous | + | When a new minor %%FreeBSD%% version is released, |
| 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. | 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. | 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. | 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 ====== |
| - | Many of us agree to focus on RELEASE first and put less focus on STABLE/ | + | There are several ways to solve this issue, |
| - | + | ||
| - | ===== 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 | + | |
| ===== Kernel module built on installation ===== | ===== Kernel module built on installation ===== | ||
| Line 36: | Line 25: | ||
| * '' | * '' | ||
| * '' | * '' | ||
| - | |||
| - | ===== 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 | ||
| ===== Package repository for minor version ===== | ===== Package repository for minor version ===== | ||
| Line 63: | Line 40: | ||
| * possible changes in the default repository configuration | * possible changes in the default repository configuration | ||
| **Additional Note**: For the older %%FreeBSD%% release, we could only keep '' | **Additional Note**: For the older %%FreeBSD%% release, we could only keep '' | ||
| + | |||
| + | ====== 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 ==== | ==== Other additional considerations ==== | ||