Bug 2059183

Is there some context here? I'm confused about why this policy is changing.

In particular, the CentOS Kmods SIG intends to build kmods for RHEL 9 once it's available on CentOS Community Build Service, and it would be helpful to have some guidance for the SIG to be able to continue supporting drivers and such on the RHEL 9 kernel as it evolves.

(In reply to Neal Gompa from comment #6)
> Is there some context here? I'm confused about why this policy is changing.
> 
> In particular, the CentOS Kmods SIG intends to build kmods for RHEL 9 once
> it's available on CentOS Community Build Service, and it would be helpful to
> have some guidance for the SIG to be able to continue supporting drivers and
> such on the RHEL 9 kernel as it evolves.

For RHEL, I don't see it makes much practical difference when the vast majority of drivers need rebuilding for a minor point release anyway due to ABI changes in symbols not on the kABI-stablelist. In this context, the kABI stablelist adds little value moving between one minor point release and the next - the value comes from maintaining a stable kABI within a point release so we do not need to recompile drivers for each and every kernel release.

As Stream has not concept of point releases or stable kABI, there is no impact whatsoever to CentOS.

(In reply to Neal Gompa from comment #6)
> In particular, the CentOS Kmods SIG intends to build kmods for RHEL 9 once
> it's available on CentOS Community Build Service, and it would be helpful to
> have some guidance for the SIG to be able to continue supporting drivers and
> such on the RHEL 9 kernel as it evolves.

Thanks for the notification about this change. I have limited access to this bug, hence the following is based on the assumption that after this change the kABI stablelist is only valid for a minor release and not for a major release anymore as it used to be.

Concerning the work of the Kmods SIG, this change very likely has only a low impact if at all.
As Phil already mentioned, most kABI tracking kernel modules must be rebuilt for each minor release anyway as there is barely any kernel module which only requires symbols on the kABI stablelist.
Some kernel modules even need to be rebuilt for the same minor release.
Hence concerning building kernel modules for RHEL 9 it is very likely that this changed policy has only limited impact.

Concerning Stream 9: The changed policy might lead to more frequent changes of the Stream 9's kABI as there is now no guarantee about kABI stability for Stream 9 anymore at all.
Before this change at least the symbols on the kABI stablelist were not allowed to be changed.
This again has little effect as long as the changes can be automatically detected, i.e., if a symbol is changed in a non-compatible way, the checksum has to be changed.
We need to detect required rebuilds for Stream automatically anyway due to the frequently changed symbols not on the stable list and higher frequency of kernel release.
How often a kernel module actually needs to be rebuilt at the end does not really matter.

However all of the above is only true if the kABI changes only require rebuilds of external kernel modules. If the changed policy also leads to more frequently required source code changes of external kernel modules this will obviously lead to an increased workload. However, considering how few symbols are actually on the kABI stablelist I doubt that anybody will actually notice a difference.

Thank you all for your thoughts on this change.
I agree with Peter's Comment#10, there might be a more frequent changes in Stream 9's kABI. The actual mechanics (symbol checksums generated with CONFIG_MODVERSIONS) will remain enabled, so the changes can be detected like they can be today with CentOS Stream 8.
We don't expect any increase of necessary changes to the kernel module source codes. Note that even today there's no commitment on stability of kernel source code interfaces (aka API).

Release note published:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.0_release_notes/index#BZ-2059183