This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Requiring Linux 3.2 for glibc 2.24
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Dmitry V. Levin" <ldv at altlinux dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 1 Feb 2016 18:06:42 +0000
- Subject: Re: Requiring Linux 3.2 for glibc 2.24
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1601311614080 dot 31071 at digraph dot polyomino dot org dot uk> <20160201133505 dot GB706 at altlinux dot org> <alpine dot DEB dot 2 dot 10 dot 1602011636530 dot 2674 at digraph dot polyomino dot org dot uk> <20160201172417 dot GA3584 at altlinux dot org>
On Mon, 1 Feb 2016, Dmitry V. Levin wrote:
> That discussion shows that there is no consensus of not supporting kernels
> not maintained at kernel.org, and rightly so, because other stable kernels
> maintained by non-kernel.org providers are widely in use.
That something is in wide use does not mean it's relevant (a) as a
platform for developing glibc itself, or (b) as a platform for running
GNU/Linux distributions much more recent than the kernel in question.
(For (b), we're not even talking August 2016, but some time after that
once glibc 2.24 has found its way into distributions.)
> There are no doubts that raising minimal kernel version to a value greater
> than 2.6.32 on x86/x86_64 will make openvz users unhappy, forcing them
> to use unstable kernels.
Or to use distributions that aren't quite so far ahead of the underlying
hosting platform, until support for newer kernels is available there.
I'd expect running new distributions on an old kernel to become
increasingly problematic over time, just like running any new software on
old distributions is; when the software vintages involved differ by more
than a few years, you get problems.
Now, you could require 3.2 everywhere except x86/x86_64 (and maybe require
3.2 headers everywhere), and get some cleanup from removing various
architecture-specific conditionals, but I'm not convinced that running a
distribution from late 2016 or later on a kernel series first released in
December 2009 is a realistic expectation for us to support.
--
Joseph S. Myers
joseph@codesourcery.com