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: Mike Frysinger <vapier at gentoo dot org>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Florian Weimer <fweimer at redhat dot com>, Pavel Emelianov <xemul at virtuozzo dot com>, "Konstantin Khorenko" <khorenko at virtuozzo dot com>
- Date: Thu, 11 Feb 2016 12:40:18 +0000
- Subject: Re: Requiring Linux 3.2 for glibc 2.24
- Authentication-results: sourceware.org; auth=none
- References: <56BB4759 dot 6040309 at redhat dot com> <D2E226D6 dot B2B03%dim at virtuozzo dot com> <20160211123343 dot GB7732 at vapier dot lan>
On 11/02/16 15:33, "Mike Frysinger" <firstname.lastname@example.org> wrote:
>On 11 Feb 2016 08:54, Dmitry Mishin wrote:
>> > On 02/09/2016 03:54 PM, Florian Weimer wrote:
>> >> On 02/09/2016 03:36 PM, Aurelien Jarno wrote:
>> >>> I am in favor of that. That said when have we tried to do so in
>> >>> stretch/sid (which will be released in 2017), people started to
>> >>> loudly that it breaks openvz. We had to revert the change given a
>> >>> VPS providers are using openvz.
>> >>> It seems that openvz is currently not ported on more recent kernels
>> >>> 2.6.32 and that it will be supported until 2019 for SLES11 and 2020
>> >>> RHEL7. This unfortunately doesn't encourage openvz to move to newer
>> >>> kernels.
>> >> 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>
>> > Oh dear.
>> Yep, we have to do this in order still allow OpenVZ users to run desired
>> inside Containers. Unfortunately, they will to run brand new Linux
>> every time they appear. :)
>> Seriously, we wouldn't do these hacks if glibc preserve compatibility
>> old Kernels.
>that makes no sense. glibc already supports 2.6.32 today. maybe you're
>misattributing the problem to distros or other packages ? off the top of
>my head, i know udev is pretty aggressive at dropping support for older
>versions of linux. however, simply lying via uname doesn't actually make
>the code work -- they're requiring newer versions because they expect the
>functionality that's supposed to be in newer versions. so unless you're
>actually backporting features too (ugh), then your system is broken.
We backport features if they are reported as "some software doesn't work
Containers", but in addition to this, we have to lie about kernel version
Of such sanity checks here and there.