Re: Requiring Linux 3.2 for glibc 2.24

[Dmitry Mishin <dim at virtuozzo dot com>]

On 11/02/16 12:14, "Florian Weimer" <fweimer@redhat.com> wrote:

>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.
That's true till some point.
First, I believe not all distributions have such define already. For
example,
RHEL/CentOS 7 does not.
Second, our hacks to falsify the kernel version are enabled by a Container
template parameter, which we specify in templates which are provisioned by
OpenVZ team. The problem is that some users (VPS hosters) prefer to make
their
own templates. And I doubt they specify fake kernel version unless it is
absolutely required by a distribution.

So, in short, there could be some users with modern distribution (like
CentOS 7)
with non-fake 2.6.32 kernel version. And they'll be affected by this
change IF
CentOS decides to bump glibc version.

BTW, is VDSO the only place for glibc to determine kernel version nowadays?

>
>(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.)
How could we help here?

>
>Florian

Thank you,
Dmitry.