On Wed, Dec 23, 2020, at 9:25 PM, Mark Mielke wrote:
On Wed, Dec 23, 2020 at 8:27 PM Neal Gompa ngompa13@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