This is the mail archive of the
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 16:46:14 +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>
On Mon, 1 Feb 2016, Dmitry V. Levin wrote:
> On Sun, Jan 31, 2016 at 04:22:07PM +0000, Joseph Myers wrote:
> > As Linux 2.6.32 has been announced to reach end-of-line next month
> > <https://lkml.org/lkml/2016/1/29/647>, I propose that for glibc 2.24 we
> > require Linux 3.2 as the minimum kernel version when glibc is used on
> > systems with the Linux kernel and there isn't already a more recent
> > architecture-specific minimum.
> There are other providers of LTS linux kernels available, for example,
> RHEL6 kernel has EOL in 2019. The change you propose would be especially
> nasty to projects like openvz.org: they provide RHEL based kernels to run
> containers, and their RHEL7 based openvz kernel is still in testing.
> Raising the bar in glibc would leave openvz users without a stable kernel
> where they would be able to run containers based on glibc > 2.23.
We discussed the containers issue when moving to 2.6.32. See the thread
starting at <https://sourceware.org/ml/libc-alpha/2014-01/msg00511.html>
(general idea of not supporting kernels not maintained upstream in
<https://sourceware.org/ml/libc-alpha/2014-01/msg00602.html>). The view
was expressed then that it was good to put pressure on such hosting
providers to fix outdated kernels
<https://sourceware.org/ml/libc-alpha/2014-01/msg00615.html>. Note that
by the time 2.24 is released, 2.6.32 will have been unmaintained at
kernel.org for six months (and 3.2 will be the oldest maintained kernel,
which is the basis on which I don't see 2.6.33 as relevant).
The proposed approach for increasing the minimum is:
(a) Update configure scripts to require the new version, and update
associated documentation of the minimum.
(b) Remove __LINUX_KERNEL_VERSION conditionals whose results are now
(c) Remove individual __ASSUME_* macros and conditionals thereon, where no
longer necessary (so not used in code for non-Linux-kernel systems that
don't define the macro, etc.). The macros can be removed in any order,
incrementally. Removal of the linux/fanotify.h configure test also comes
Joseph S. Myers