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

James Cassell

fedoraproject at cyberpear.com
Thu Dec 24 15:20:36 UTC 2020



On Wed, Dec 23, 2020, at 9:25 PM, Mark Mielke wrote:
> On Wed, Dec 23, 2020 at 8:27 PM Neal Gompa <ngompa13 at gmail.com> wrote:
> > To your comment about Red Hat not using LTS kernels, LTS kernels do
> > not maintain kABI upstream either, so it doesn't save any effort for
> > Red Hat one way or another. If anything, being based on an LTS kernel
> > would do Red Hat less favors because they're under pressure to conform
> > to something similar to the upstream LTS kernel. Since the upstream
> > LTS kernel already doesn't match the RHEL kernel lifecycle and Red Hat
> > engineers would wind up doing a bunch of work anyway for the kABI
> > stabilization and live kernel patching features, the non-LTS kernels
> > are strategically better because there's less churn in them and more
> > long-term flexibility.
> 
> This is an interesting point. Oracle UEK R6, as used in OL 7 and OL 8,
> is tied to Linux 5.4.17, and I think the above might be a good summary
> of why this is a good thing. One part of this is to set the
> expectation for what kABI is supported. The other part is to gain
> access to newer features, and reduce the cost of maintaining a high
> quality back port that still adheres to this kABI. By deploying Oracle
> UEK R6 simultaneously to both OL 7 and OL 8, they have effectively
> separated the kernel from the OS distro, allowing for both elements to
> be achieved. This seems like something that could be useful to do for
> the broader EL community.

Red Hat already does this in effect, supporting RHEL 6,7,8 user spaces on RHEL 7 and 8 kernels, via containers.

V/r,
James Cassell


More information about the CentOS-devel mailing list