This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Requiring Linux 3.2 for glibc 2.24
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Florian Weimer <fweimer at redhat dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 1 Feb 2016 11:29:34 -0200
- 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> <56AE4D5F dot 9080105 at redhat dot com> <E549E742-5E32-4C68-947A-40F32EB61FB8 at linaro dot org> <56AE69A0 dot 4030302 at redhat dot com> <1454323323 dot 4592 dot 272 dot camel at localhost dot localdomain> <56AF37E4 dot 2080302 at redhat dot com>
On 01-02-2016 08:48, Florian Weimer wrote:
> On 02/01/2016 11:42 AM, Torvald Riegel wrote:
>> On Sun, 2016-01-31 at 21:08 +0100, Florian Weimer wrote:
>>> On 01/31/2016 07:30 PM, Adhemerval Zanella wrote:
>>>
>>>> I see no compelling reason to switch to a non-supported version. Also I would have prefer GLIBC to keep supporting the minimum LTS kernel version instead of a specific version.
>>>
>>> It's mostly 2.6.32 on everything except Alpha. These cleanups won't
>>> happen over night, especially not the less obvious ones (such as the
>>> ST_VALID cleanup). I just wonder if we could support 2.6.32 with little
>>> more effort for a one or more future releases.
>>
>> So, IIUC, this wouldn't be a change for anything but Alpha? Is Alpha
>> really worth this extra treatment?
>
> No, it's about substantial cleanups which preserve compatibility with
> 2.6.32, except on Alpha, where 2.6.33 will be required.
>
> The cleanups are exactly the same as we would do when heading towards a
> 3.2 kernel baseline. It is not a detour at all.
>
> Are different way of phrasing my proposal: Let's do these cleanups first
> which were previously blocked by Alpha, and when they are done, consider
> the switch to 3.2 as a baseline.
It sounds reasonable, although just raising the minimum version will result
in some better code generation. Anyway, I think we have plenty of time to
do the cleanup before effectively raising the kernel version.