This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH] AARCH64/ILP32: introduce kernel time types
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Yury Norov <ynorov at caviumnetworks dot com>
- Cc: libc-alpha at sourceware dot org, vapier at gentoo dot org, joseph at codesourcery dot com, cmetcalf at tilera dot com, pinskia at gmail dot com, cmetcalf at mellanox dot com, szabolcs dot nagy at arm dot com, bamvor dot zhangjian at huawei dot com, schwab at suse dot de, catalin dot marinas at arm dot com, fweimer at redhat dot com, Prasun dot Kapoor at cavium dot com, maxim dot kuvyrkov at linaro dot org
- Date: Tue, 28 Jun 2016 10:59:56 +0200
- Subject: Re: [RFC PATCH] AARCH64/ILP32: introduce kernel time types
- Authentication-results: sourceware.org; auth=none
- References: <1467103498-24243-1-git-send-email-ynorov at caviumnetworks dot com>
On Tuesday, June 28, 2016 11:44:58 AM CEST Yury Norov wrote:
> Structures utmp and utmpx are shared between ilp32 and native ABIs,
> and so should have same layout. As now, architectures where this
> compatibility is required enable __WORDSIZE_TIME64_COMPAT32 option,
> and so make lp64 utmp{x} backward-compatible to ilp32 ones.
>
> AARCH64 doesn't require such compatibility, and so we can do opposite
> conversion.
>
> This patch introduces new option __KERNEL_TIME_T_MATCHES_TIME64_T,
> and adds internal __ktime_t, __kusecond_t, __ksusecond_t types,
> that are native-sized for normal case, and forced to 64-bit size if
> __KERNEL_TIME_T_MATCHES_TIME64_T is enabled.
>
> This is generic solution because we are facing y2038 problem, and
> all new ABIs should follow this convention. This approach might also
> be used for RISC-V as default.
>
> If no objections, I'll incorporate it to v2 of AARCH64/ILP32 patchset.
>
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
I don't think it's a good idea to start with AARCH64/ILP32 doing this,
there are way to many interdependencies:
* I've been working on adding 64-bit time_t support to the kernel for
multiple years now, and most of the work is still pending. For
now, 32-bit architectures are stuck with 32-bit time_t, but we
will fix them all.
* x86/x32 tried defining a user space ABI that had 32-bit time_t,
but that never worked out properly and we still run into new
bugs because of this. We discussed this for aarch64/ilp32 in
great length (also over multiple years) and had a very clear
decision that this would be handled differently, by using the
regular 32-bit syscall ABI in the kernel and introduce 64-bit
time_t at the same time as all other 32-bit architectures do.
* There is another long-running effort to add support for 64-bit
time_t to glibc, currently in the discussion phase but
now converging on an approach. This will introduce 64-bit
time_t for all 32-bit architectures as an option (while still
supporting 32-bit time_t), but it will only work correctly
in all corner cases when running on a kernel that also support
it (see first point). See
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for
more details.
I think glibc should do what you have in your patch, but it
should not become a prerequisite for the aarch64/ilp32 support,
otherwise it will take a few more years to have a working port.
Arnd