Re: [RFC PATCH] AARCH64/ILP32: introduce kernel time types

[Yury Norov <ynorov at caviumnetworks dot com>]

On Tue, Jun 28, 2016 at 10:59:56AM +0200, Arnd Bergmann wrote:
> 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.

This is not about 64-bit time_t. This is about new type __ktime_t that
can replace time_t where it's safe.

> 
> * 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

If generally this approach is OK, I can split the patch to completely
generic part, and small part that only enables __KERNEL_TIME_T_MATCHES_TIME64_T
in aarch64. First one can be applied independently from aarch64/ilp32.

Yury.