Stable ABI for 2009.1 Kernel
From Mandriva Community Wiki
Contents |
Using ABI versioning in Mandriva Kernels
This is the initial version of the document describing the necessary steps to have a system to manage changes between the updates of stable and OEM Mandriva Kernels that does not require module rebuilds on every kernel update.
The problem
The current Mandriva policy for distributing Kernel updates requires that all DKMS modules be built and distributed together with the kernel packages. Also, when not installing these pre-built DKMSs, users have to rebuild the source DKMS modules for the newer kernel.
In OEM setups sometimes it is not possible to provide security updates for the kernel packages because some proprietary modules will not be available for the newer kernel.
The proposed solution
The proposed solution tries to mitigate it by adopting a new location where built DKMS modules will be installed. This location will be shared between all the kernels that adhere to a given "kernel ABI version".
The ABI version is just a number like rpm's EPOCH that is increased by the packager all the time a "ABI change" is reported by the script PATCHES/scripts/abi.
The location where DKMS modules will be installed is /lib/modules/<KVER>/extra/. This, in turn, is a link that points to /lib/modules/kernel-abi-<FLAVOUR>-<ABIVERSION>, which is the shared location for those kernels that adhere for a given ABI.
Suppose the user installs dkms-nvidia96xx and the running kernel is 2.6.29.1-desktop-1mnb, whose ABI version is 1. It will get built and installed into /lib/modules/2.6.29-desktop-1mnb/extra/dkms/drivers/char/drm/. When a new kernel appears (say 2.6.29.1-desktop-2mnb), the extra/ directory of this package will also be pointing to /lib/modules/kernel-abi-desktop-1/ and thus all the installed DKMS modules will be also be accessible by this kernel.
This model is roughly based on what Ubuntu does, differing in the way DKMS modules and kernel versions are handled.
What must be changed
The kernel package
In order to allow loading modules from different kernels safely, the configuration options CONFIG_MODVERSIONS and CONFIG_MODULE_SRCVERSION_ALL should be enabled.
The package was also changed to provide the kernel-abi-<FLAVOUR>-<ABIVERSION> directory and have the extra/ symlink.
It also has been changed to have a Provides: kernel-abi-<FLAVOUR> = <ABIVERSION>, but it is not currently being used.
DKMS
DKMS was patched to install built modules into extra/.
It also has been changed to locate the built modules in this directory when performing dkms status. A new module status has been added: installed-abi, which indicates the built module is available for use and comes from another ABI-compatible kernel.
dkms_autoinstaller has been patched to handle the installed-abi status a not try to rebuild it again.
In order to allow using modules from more recent kernels in the older ones, dkms status will provide the extra status needs-depmod when any built module is newer than modules.dep. dkms_autoinstaller will understand it and run depmod so that these modules will be available for use.
dkms build has been changed to keep Module.symvers from each module built. It will also merge these saved files from all modules when building a new one in order to allow modules depending each other.
harddrake
It should be changed to also look into extra/ when checking for the presence of nvidia modules.
Kernel release workflow
The ABI description files will be generated during the build of the kernel package based on the Module.symvers files generated for each kernel flavour. These files will be compared against the ones from the previous kernel release, which are archived at SOURCES/abi-<ARCH>.tar.
diff -u is used to compare the two ABI descriptions. When symbols are modified or removed (ie. when we find "-" in the diff output) there is an ABI breakage. When symbols are only added, only a warning is issued.
When the kernel packager is going to build the release packages. It will have to build the packages and then run PATCHES/scripts/abi --check to ensure the ABI of the upcoming kernel is compatible with the older ones. When the script notifies that there was an ABI breakage, the package must bump the %abiver macro in the spec file, build the kernel again and then run PATCHES/scripts/abi --update
Testing
The patches on the kernel are being kept on the test-stable-abi branch. The latest packages built are available for testing at http://users.mandriva.com.br/~bogdano/abi/.
The DKMS branch with the patches is stable-abi.
Discussion
How frequently the ABI breaks?
One of the main motivations to adopt this system lies on the expectation that there will be few kernel ABI breaks during the upstream stable release cycle. In order to validate it, all the 2.6.27.yy kernel releases where built and its Module.symvers files where saved to be compared against each other. This is the result:
# sha1sum # symvers d90ac28f4a537714a7e128b08bebbd1c71bdcca7 patch-2.6.27.1.bz2.symvers d90ac28f4a537714a7e128b08bebbd1c71bdcca7 patch-2.6.27.2.bz2.symvers d90ac28f4a537714a7e128b08bebbd1c71bdcca7 patch-2.6.27.3.bz2.symvers d90ac28f4a537714a7e128b08bebbd1c71bdcca7 patch-2.6.27.4.bz2.symvers a808b59a2866ca5ec4c36a55dbb207f34605d4c6 patch-2.6.27.5.bz2.symvers a808b59a2866ca5ec4c36a55dbb207f34605d4c6 patch-2.6.27.6.bz2.symvers 8ac7d36e197df1dbf6bcfc49d4909d9f98abc516 patch-2.6.27.7.bz2.symvers 3a8460f57c92ba095c9f05a1e71b3a9130ff9608 patch-2.6.27.8.bz2.symvers 700214bbc345281b78d2e3f55ce9e42b5a23fd02 patch-2.6.27.9.bz2.symvers 700214bbc345281b78d2e3f55ce9e42b5a23fd02 patch-2.6.27.10.bz2.symvers 700214bbc345281b78d2e3f55ce9e42b5a23fd02 patch-2.6.27.11.bz2.symvers 003a549c3cc5e4cb61a4e77ab29b0019ab9c091c patch-2.6.27.12.bz2.symvers b304cb22079faf83a086de3d3fcc723f37f64300 patch-2.6.27.13.bz2.symvers 8f537aa1eacf50e3242f5dd2173f771366a70709 patch-2.6.27.14.bz2.symvers 2c3eea9b6c8577b9e669cd77ae0f4bd93cb8bac9 patch-2.6.27.15.bz2.symvers e83655b0d37173af9886d775a460ae4242d2a6e3 patch-2.6.27.16.bz2.symvers e83655b0d37173af9886d775a460ae4242d2a6e3 patch-2.6.27.17.bz2.symvers e83655b0d37173af9886d775a460ae4242d2a6e3 patch-2.6.27.18.bz2.symvers e83655b0d37173af9886d775a460ae4242d2a6e3 patch-2.6.27.19.bz2.symvers 49391421f64bf56d5f98a54348c958504ad7d6df patch-2.6.27.20.bz2.symvers
It makes clear that the ABI doesn't last more than 4 stable releases. This is less than expected given the fact that there is one stable release each ~1.5 weeks and we release a stable kernel monthly. We would have an ABI break in every stable release.
Pros
- no need to build DKMS modules again;
- no need to distribute pre-built DKMS modules on every stable kernel update (there is a cost in building the DKMSs in every update: see an example kernel advisory);
- allows vendors providing us proprietary modules for specific kernel ABIs;
- allows providing security updates for these kernels using proprietary drivers;
Cons
The counterarguments are mostly based on checking whether the Pros are realistic and not based on handling corner cases:
- won't these stable updates result in ABI bump on every release?
- the ABI could be refined into per-module-ABI -spuk
- will we really provide updates for these OEMs that rely on proprietary drivers?
- do we really have vendors interested in providing proprietary drivers for stable releases?
- won't it result in more confunsion and points of failure?
- any time the ABI breaks (and how common is it?), "Pros" 1 and 4 are broken, and 3 is made quite irrelevant (the module will work, but only with old ABI) -spuk
- the current process of providing rebuilt DKMSs was problematic when first introduced, but now it has been done without trouble for a good number of kernel releases already -spuk
- making DKMS rebuilds mostly "unneeded" may also incur in making them more error prone, by being less used/tested -spuk
- the ABI "calculus" must be as correct as possible, errors in it require bumping the ABI version, making the ABI useless -spuk
- I believe exported C macros and inlineable functions, with their whole body, must be considered part of the ABI, as, otherwise, possible (security) fixes on their code wouldn't be present on the old built modules -spuk
Resolution
It has been decided it will not be included in 2009.1, as it seems we can't rely on the stability of the ABI for upstream stable releases, as shown above. More research on the matter is needed.
