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: Linux kernel version support policy


On Wed, Jan 29, 2014 at 02:46:44PM +0000, Joseph S. Myers wrote:
> On Wed, 29 Jan 2014, Siddhesh Poyarekar wrote:
> 
> > On Wed, Jan 29, 2014 at 03:20:00AM -0700, Adam Conrad wrote:
> > > On Wed, Jan 29, 2014 at 03:08:05PM +1000, Allan McRae wrote:
> > > > 
> > > > Debian: 2.6.32
> > > > Ubuntu: 2.6.32 or 2.6.24 depending on architecture
> > > 
> > > This will be 2.6.32 across the board the day we ditch some old 2.6.24
> > > Xen-on-x86 kit in our infrastructure.  We chose 2.6.32 intentionally
> > > to be backward compatible with setting up chroots on squeeze, lucid,
> > > and RHEL6.  Anything older than that really doesn't seem worth me even
> > > trying to support.
> > 
> > RHEL-6 runs the 2.6.32 kernel, but its glibc is built with
> > --enable-kernel=2.6.18.
> 
> So, do you have views on:
> 
> * general policy (my suggestion is that we default to not supporting 
> kernel versions not maintained upstream, unless we believe in a particular 
> case that there are important distribution versions using those kernels 
> that make it desirable to support using them);
> 
> * moving to requiring 2.6.32, the oldest currently-maintained kernel 
> series, for glibc 2.20 (release due July 2014)?

While on the one hand I'd like to avoid breaking things for users of
OpenVZ-based hosting providers with outdated kernels, I think I'd
rather see glibc putting pressure on those providers to fix their
outdated, buggy, and likely-insecure kernels. So I'm mildly in favor
of bumping the requirement to 2.6.32.

Rich


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