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