This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Requiring Linux 3.2 for glibc 2.24


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 
constant.

(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 
in here.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]