Re: Minimum kernel (formal ?) support policy

[Carlos O'Donell <carlos at redhat dot com>]

On 1/15/19 12:21 PM, Romain GEISSLER wrote:
> I am working in a company and from time to time we wonder which
> version of OS to use, and which version of toolchain to use (given
> that we build our own toolchain in non standard paths, and try as
> much as possible not to use any library from the underlying OS,
> including glibc). When this happens comes the question of the kernel
> vs glibc compatibility.
> 
> Current glibc require for most architecture a Linux kernel >= 3.2,
> this is at least the case for x86_64 which we are currently using. I
> expect that in the future, this requirement may evolve to newer
> kernels. When this is done, do you follow any kind of formal rules or
> do you choose the minimal kernel on a case by case basis ? For
> example I always thought that you tried to look at this page
> https://www.kernel.org/category/releases.html and used the oldest
> still supported kernel as a minimum for glibc, but it looks like
> right now you still support kernel 3.2 while the oldest supported
> kernel is 3.16. So is there any rule on this side for the glibc
> project ?

Raising the minimum supported Linux kernel is quite disruptive,
and so we try to do it only when it would yield a net gain on the
maintenance costs for the project.

The general process for moving the minimum supported Linux kernel
version is this:

* Start a discussion on libc-alpha.

* Discuss the benefit of moving the minimum kernel version forward.

* Gather consensus and make the change.

For example:

"Require Linux 3.2 except on x86 / x86_64, 3.2 headers everywhere"
https://sourceware.org/ml/libc-alpha/2016-02/msg00689.html
 
> Now a question more Red Hat specific. Several core contributor are
> working for Red Hat, and I expect they have some kind of internal
> rules. For example is it a goal that each time glibc 2.X is released
> it shall run on the latest RHEL kernel ? This kind of scenario
> happens more and more with the cloud current trends where enterprise
> uses RHEL-based VMs as hosts, running proprietary Docker containers
> with their own glibc which may be newer than the glibc normally found
> on RHEL distributions.

The project should move forward with whatever choices are best for
the project regarding support for the kernel versions to support.

If there are specific Red Hat needs I express them as part of the
consensus process. There are no hard-and-fast rules here, the market
evolves too fast for any kind of ossified process to apply.

Your choice of container host kernel will limit the containers you
can run because of the minimum glibc kernel requirement.

A RHEL7 x86_64-based VM is using a 3.10-based kernel can run all
newer glibc since glibc as of 2.26 requires only 3.2-based kernels.

One day that RHEL7 VM will be unable to run newer glibc. When that
happens is difficult to predict.

There are some arguments against having this kind of "line in the
sand" approach to kernel versions, some argue that it should be
based on actual capabilities e.g. finer grained. While true a finer
grained checking would increase maintenance costs and the testing
matrix would become much more complicated. Thus the "minimum kernel
version" remains the simplest and easiest solution to the problem.

Does that answer your question?

-- 
Cheers,
Carlos.