This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/4] Nios II port submission
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Chung-Lin Tang <chunglin_tang at mentor dot com>
- Cc: Chung-Lin Tang <cltang at codesourcery dot com>, <libc-alpha at sourceware dot org>, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Wed, 23 Apr 2014 14:17:44 +0000
- Subject: Re: [PATCH 0/4] Nios II port submission
- Authentication-results: sourceware.org; auth=none
- References: <53359790 dot 3030301 at codesourcery dot com> <Pine dot LNX dot 4 dot 64 dot 1403281610240 dot 6067 at digraph dot polyomino dot org dot uk> <5343BFD4 dot 3020200 at mentor dot com>
On Tue, 8 Apr 2014, Chung-Lin Tang wrote:
> On 14/3/29 12:11 AM, Joseph S. Myers wrote:
> > On Fri, 28 Mar 2014, Chung-Lin Tang wrote:
> >
> >> (1) The configure bits still refer to Linux version 3.8 as the minimum
> >> version, which is planned to be updated when Altera successfully gets
> >> their kernel port upstream (presumed to be within the 3.15 cycle, the
> >> comments already reflect this).
> >
> > Following the principle established with MIPS NaN-2008, the version should
> > be set to 10.0.0 until there is an actual kernel upstream with the
> > support.
> >
>
> As a question on policy, can a new port be committed (and included in a
> release) in this 10.0.0 form before the kernel port actually gets
> accepted upstream?
Yes (given the MIPS precedent, again) - but it would still seem a good
idea to try to resolve ABI-related issues from the initial kernel review
first.
Thus, you'll need to sort out what the kernel/userspace ABI should look
like for asm-generic platforms that are 32-bit but with 64-bit time_t in
the kernel (and any other types that get changed as a result of that
discussion). And then work out what the ABI should be like in glibc,
which may well involve changing various glibc headers that relate to the
affected part of the kernel/userspace ABI. I presume glibc should use
64-bit time_t if the kernel does. But please make sure you don't repeat
the mistake made for x32 and discussed in bug 16437 - tv_nsec should
remain "long" (in userspace, and if the kernel/userspace ABI does
something else then glibc will need copying code as discussed in that
bug).
I don't know the upstream kernel status of AArch64 ILP32. If it's not
upstream yet then it will be another linux-generic case with 64-bit time_t
(so discussion with AArch64 ILP32 people may be helpful for getting the
ABI right).
--
Joseph S. Myers
joseph@codesourcery.com