Minimum kernel (formal ?) support policy

[Romain GEISSLER <romain dot geissler at amadeus dot com>]

Hi,

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 ?

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.

Thanks,
Romain