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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 16 Jan 2014 00:57:38 +0000
- 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>
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.
--
Joseph S. Myers
joseph@codesourcery.com