On Wed, Dec 23, 2020 at 7:15 PM Neal Gompa <ngompa13 at gmail.com> wrote: > On Wed, Dec 23, 2020 at 4:38 PM Phil Perry <pperry at elrepo.org> wrote: > > If Red Hat really wanted to fix this in (a) kernel, the solution would > > have been to accept the repeated upstream requests to backport the > > driver into the RHEL kernel, but that idea/request has been rejected. > No. The correct fix here is to start blocking RHEL kernel updates > against third-party Free Software kernel module packages to ensure > compatibility isn't broken and the kernel ABI stops breaking on every > kernel version series. The reason it keeps breaking is because there's > no current mechanism in which these are tested together to validate > them for release. I think you are correct. I also think there is a long-ish road to get here. :-) Overall, it would have the best long-term results. It requires everyone that has requirements, document their requirements as automated tests. But, it would put a damper on "new feature that needs large kernel ABI changes to cost effectively backport", such as the OverlayFS changes done in RHEL 7 as one of many such examples. The choice to use Linux 4.18 is particularly problematic, since it wasn't an LTS kernel. :-( 5 years is a long time to wait for new breaking features in the kernel. > More than most, I get why you're upset about the kABI always breaking > as kernel updates push out, but instead of just saying "it's not > suitable", we should be building solutions to *make* it suitable for > the Enterprise. It's *bad* that the RHEL kernel breaks its own > promises so often (which is a relatively new thing, in my experience), > and we should be implementing safeguards to stop it from happening > going forward. Yes. Although, in the mean-time... -- Mark Mielke <mark.mielke at gmail.com>