Re: Requiring Linux 3.2 for glibc 2.24

[Florian Weimer <fweimer at redhat dot com>]

On 02/11/2016 09:54 AM, Dmitry Mishin wrote:
>> On 02/09/2016 03:54 PM, Florian Weimer wrote:

>>> I've got access to a Virtuozzo container which runs on a commercially
>>> supported (?) 3.10 kernel variant.
>>
> 
> It turns out it's lying about the kernel version:
> 
> <https://bugs.openvz.org/browse/OVZ-5843>

> Yep, we have to do this in order still allow OpenVZ users to run desired software
> inside Containers. Unfortunately, they will to run brand new Linux distributions
> every time they appear. :)

Thanks for joining the discussion.

> Seriously, we wouldn't do these hacks if glibc preserve compatibility with
> old Kernels.

Currently, glibc upstream is still compatible with Linux 2.6.32 (and
will use newer kernel features if they are available).  That's also the
minimum kernel version we specify for Fedora and Red Hat Enterprise Linux.

I don't think we have yet a complete understanding what is going on.  I
suspect that some downstream distributions use a configuration option
which glibc provides to raise the minimum kernel requirement.  (This
leads to a slightly smaller code size and a bit more efficiency.)

But if this is correct, not much will change from an OpenVZ point of
view if we gradually increase the minimum kernel version required by
glibc upstream.  True, future Fedora versions will require a newer
kernel version.  But the Fedora glibc will have the same kernel
requirements as other distributions which already pass
--enable-kernel=3.2.0 or --enable-kernel=3.10.0 at glibc configure time,
so that will not cause any additional problems to you over what you have
to deal with today.

So in short, I don't see how the overall situation with regards to
containers worsens if glibc adopts a minimum kernel version of 3.2.

(I am worried about /proc and /sys layout differences between the
various container technologies out there, and there have already been
proposals discussed on this list which would not work in certain
containers, without us realizing at the time that there would be a
compatibility issue.  Without more upstream testing involving various
container technologies, such issues, if they make it into the code base,
will only be caught extremely late.)

Florian