This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Set arch_minimum_kernel for powerpc*le
- From: Alan Modra <amodra at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 16 Jan 2014 13:08:37 +1030
- Subject: Re: Set arch_minimum_kernel for powerpc*le
- Authentication-results: sourceware.org; auth=none
- References: <20140115094039 dot GX5390 at bubble dot grove dot modra dot org> <Pine dot LNX dot 4 dot 64 dot 1401151600030 dot 19695 at digraph dot polyomino dot org dot uk> <20140116003137 dot GA5390 at bubble dot grove dot modra dot org> <Pine dot LNX dot 4 dot 64 dot 1401160051200 dot 27886 at digraph dot polyomino dot org dot uk>
On Thu, Jan 16, 2014 at 12:57:38AM +0000, Joseph S. Myers wrote:
> On Thu, 16 Jan 2014, Alan Modra wrote:
>
> > You are correct that the first kernel.org release with working support
> > was 3.13. However, there are unofficial kernels dating back to 3.10,
> > and sometimes distros backport support for particular features to an
> > older kernel. That's why I chose 3.10. --enable-kernel doesn't allow
> > you to specify less than arch_minimum_kernel.
>
> Distros can of course have a local change to arch_minimum_kernel (and that
> won't break any sort of compatibility). The practice followed for ARM
> EABI, AArch64, x32 etc. is to use the minimum kernel version with the
> relevant support rather than the first version for which support was
> posted. (For ARM EABI of course the version is now the minimum glibc
> supports at all - but when added to glibc, 2.6.16 reflected when the
> support went in the kernel, whereas the patches were first posted for
> 2.6.14 and some people used 2.6.14 kernels with the patches.)
>
> The reasoning is that when doing global cleanups, the given version is the
> earliest one you ever need to look at to see what kernel support was
> present when - and you never need when doing such cleanups to look at any
> unofficial patches, only actual kernel.org release versions (or git for
> very new features). If the version number used is 10.0.0 (kernel support
> not yet upstream at all, as in the MIPS NaN2008 case) then it's up to the
> relevant architecture maintainers to help in such cases as needed.
OK, I'll change it to 3.13.
--
Alan Modra
Australia Development Lab, IBM