#14 Reconsidering kABI tracking kmods
Closed 12 days ago by pjgeorg. Opened 2 months ago by pjgeorg.

I have recently been reconsidering using kABI tracking kmods, i.e. using the weak-updates mechanism, instead of recompiling all kmods for every kernel release.

The current approach without using this mechanism is easy but also has some drawbacks:
1. It obviously involves recompiling for every kernel release even if the kABI has not changed at all. This also applies to DDs.
2. There is no way to disallow kernel updates without updating all kmods. In case of using kABI tracking kmods there is at least a chance the old kmods will still work with the new kernel.

These are known drawbacks and at least my opionion is that these are not too bad as long as kernel updates do not happen to often. With c9s now being available it seems the frequency is increased. I.e. latest kernel updates:

  • kernel-5.14.0-4.el9 2021-09-23 12:30:02 
  • kernel-5.14.0-3.el9 2021-09-17 17:55:17 
  • kernel-5.14.0-2.el9 2021-09-13 23:39:04

Actually for all kmods I currently build for c9s, none of these kernel updates changed any relevant kABI. I.e. the version compiled for kernel-5.14.0-1.el9 would work for all kernel versions.

Hence I tought about how we could do kABI tracking kmods by:
1. Converting one of the available kmod packages to a kABI tracking kmod, see https://pagure.io/fork/pjgeorg/centos-sig-kmods/kmod-aacraid/c/96d3a60be7b065ebfa8bfd36531e3b1812bf8e62?branch=c8s-sig-kmods
2. Creating a new repository with auto-generated data probably useful to later auto-detect relevant kABI changes: https://pagure.io/centos-sig-kmods/kabi

In 1. I dislike that we have to specify the ko files in %install and %post. I was not able to find a nice solution yet to avoid this duplication.

Next step is to automate re-compilation in case of kABI changes. Just already wanted report progress so far. Will update further progress here.

Feel free to comment in case you have any input/questions/...


Metadata Update from @pjgeorg:
- Issue assigned to pjgeorg

2 months ago

For a test I converted 24 packages of packages-main to "kABI tracking kmods" and built them against kernel-4.18.0-305.7.1.el8_4 for c8 and kernel-4.18-315.el8 for c8s.

As expected it turned out that the packages for c8 do not need to be rebuilt for any of the newer kernel (tested up to 4.18.0-305.19.1.el8_4).

For c8s the result is actually a bit surprising to me:

  • 4.18.0-326.el8: 3
  • 4.18.0-331.el8: 2
  • 4.18.0-338.el8: 7

I.e. for these three kernel updates the probability that a kmod needs to be rebuilt is between 8 to 30%. On average it is ~17%. This is lower than I expected.
kmod-iwlegacy is the only kmod that required rebuilding more than once (for -326 and -331).

My conclusion: Convert to kABI tracking kmods. Especially as required rebuilds can be easily auto-detected using the data available in the auto-generated repository https://pagure.io/centos-sig-kmods/kabi

As there have been no objections I already converted all kmods maintained by myself to kABI tracking kmods. All kmods released so far are kABI tracking.

Closing this issue as I do not think there is anything left to disucss. Just leave a note that we might want to document internal process/suggestions at some point.

Metadata Update from @pjgeorg:
- Issue status updated to: Closed (was: Open)

12 days ago

Login to comment on this ticket.

Metadata