[CentOS-devel] Balancing the needs around the RHEL platform

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>