This is the mail archive of the
mailing list for the glibc project.
Re: Requiring Linux 3.2 for glibc 2.24
- From: Dmitry Mishin <dim at virtuozzo dot com>
- To: Florian Weimer <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: Pavel Emelianov <xemul at virtuozzo dot com>, Konstantin Khorenko <khorenko at virtuozzo dot com>
- Date: Thu, 11 Feb 2016 10:08:42 +0000
- Subject: Re: Requiring Linux 3.2 for glibc 2.24
- Authentication-results: sourceware.org; auth=none
- References: <D2E226D6 dot B2B03%dim at virtuozzo dot com> <56BC50DF dot 9020500 at redhat dot com>
On 11/02/16 12:14, "Florian Weimer" <email@example.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:
>> Yep, we have to do this in order still allow OpenVZ users to run
>> inside Containers. Unfortunately, they will to run brand new Linux
>> every time they appear. :)
>Thanks for joining the discussion.
>> Seriously, we wouldn't do these hacks if glibc preserve compatibility
>> 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
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
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
with non-fake 2.6.32 kernel version. And they'll be affected by this
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?