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, again


On 05/04/2017 07:24 AM, Joseph Myers wrote:
> On Thu, 4 May 2017, Carlos O'Donell wrote:
> 
>> What about the next step though? And the next? Moving beyond linux 3.10 would
>> mean that any future RHEL which is rebased to the newest glibc would not be
>> able to easily run in a container on RHEL 7 using a RHEL 7 kernel. 
>> Taking note that RHEL7 has support until 2024 at a minimum.
> 
> My view is that we base things on the oldest supported kernel version 
> listed at https://www.kernel.org/category/releases.html - remembering that 
> distributions supporting a distribution kernel long term may choose to 
> contribute to maintaining the upstream kernel for the community, and this 
> may mean some of the kernels listed there in fact live on with other 
> maintainers beyond the dates currently shown there.

That's a very good argument, and a similar argument can be made for FSF
supported versions of GCC and I can't argue against that.
 
> Based on the dates shown there, we might consider moving from a 3.2 
> minimum to a 3.16 minimum for glibc 2.28 (Aug 2018) or 2.29 (Feb 2019).  
> But actually it doesn't look like there's any difference between 3.2 and 
> 3.16 for features glibc cares about on x86 / x86_64 (whereas there *are* 
> cleanups possible by moving from 2.6.32 to 3.2), so there would be very 
> little cost to keeping the version back on some architectures (while 
> moving to require 3.16 on other architectures) if that makes sense at the 
> time.  And of course if 3.10, say, is in fact still supported when 3.2 
> ceases to be, that rather than 3.16 would be the version to consider.

I think I've outlined another argument in my downstream email. That the
abort we issue for being on too old a kernel may be too catastropic here
and that there might be a middle ground where such applications could work
and we don't let them.

-- 
Cheers,
Carlos.


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