Leo Famulari <l...@famulari.name> writes: > On Mon, Feb 19, 2018 at 08:22:29PM -0500, Leo Famulari wrote: >> My questions are, how does the glibc team choose the minimum kernel >> version? What could go wrong if we apply this patch and somebody uses >> Guix on a pre-3.2.0 kernel? >> >> Perhaps they simply chose to not support glibc on any kernel that is not >> supported upstream; 3.2.x is the oldest supported release series. But, >> we should have some idea of their reasoning, in my opinion. > > As far as I can tell, the discussion started on the libc-alpha mailing > list in January 2016: > > https://sourceware.org/ml/libc-alpha/2016-01/msg00885.html > > ... and continued into February: > > https://sourceware.org/ml/libc-alpha/2016-02/msg00002.html > > These messages can provide some useful context.
The only reason for moving the lower bound to Linux 3.2 is that 2.6 has reached EOL. This allows the glibc developers to assume certain kernel features and simplify their code. The RHEL kernels are special, though, in that they are continuously patched beyond recognition, backporting features. A RHEL 2.6.32 kernel is very different from a stock 2.6.32 kernel. The patch explicitly permits a *single* extra kernel version (0x020620 = 2.6.32) at runtime, not *all* older kernels, so it isn’t as bad as it may seem. For future updates to the glibc we would have to re-evaluate if the current RHEL 6.x kernel still supports all features the glibc expects, and decide once more if we can justify patching glibc to allow that one particular kernel version. -- Ricardo
