This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Linux kernel version support policy
- From: Rich Felker <dalias at aerifal dot cx>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: David Miller <davem at davemloft dot net>, libc-alpha at sourceware dot org, joseph at codesourcery dot com, aurel32 at debian dot org
- Date: Tue, 28 Jan 2014 21:10:16 -0500
- Subject: Re: Linux kernel version support policy
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401272237400 dot 14736 at digraph dot polyomino dot org dot uk> <3591302 dot 5mrdmfoV2Y at vapier> <20140127 dot 161754 dot 1207156302138039240 dot davem at davemloft dot net> <3104304 dot iNEJkBTBu7 at vapier>
On Mon, Jan 27, 2014 at 07:47:13PM -0500, Mike Frysinger wrote:
> On Monday, January 27, 2014 16:17:54 David Miller wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > > i still see people running 2.6.18 kernels today. usually in server
> > > environments like old RHEL 5 or OpenVZ or Xen instances.
> >
> > Are they upgrading to current versions of glibc?
>
> yes. they control the userland, not the kernel.
While I'd like to bump the requirement, I see this as the best
argument for NOT doing so. There are a lot of environments, especially
cheap OpenVZ-based hosting, where the userland is provided completely
by the customer/user who WANTS to be up-to-date, but who's stuck with
a backwards kernel from their hosting provider.
Do we have a list of things that changed between the current
requirement and 2.6.32 that would allow simplifying or otherwise
improving glibc code if glibc could assume the newer version?
Rich