Re: Final (?) time64 proposal

[Rich Felker <dalias@libc.org>]

On Wed, Jul 24, 2019 at 01:31:42AM -0400, Rich Felker wrote:
> With that said, the following are the functions I've identified as
> still interfacing with the kernel in ways that involve time_t:
> 
> - clock_gettime **
> - clock_settime **
> - clock_adjtime **
> - clock_nanosleep
> - timer_gettime
> - timer_settime
> - timerfd_gettime
> - timerfd_settime
> - utimensat **
> - mq_timedsend **
> - mq_timedreceive **
> - getitimer
> - setitimer
> - select
> - pselect
> - ppoll
> - recvmmsg ?
> - sigtimedwait
> - semtimedop
> - clock_getres
> - sched_rr_get_interval
> - __timedwait (backend for all timed futex waits)
> - getrusage
> - wait4
> - wait3
> - setsockopt
> - getsockopt
> - shmctl ***
> - semctl ***
> - msgctl ***
> - ioctl
> - recvmsg ?

I think a good next-step here would be modifying all of the above to
go through an intermediate kernel-type struct when using the existing
syscalls. This should not change behavior anywhere except for a slight
increase in size/time-spent, but will set things up so that, when the
time_t definition is switched over, everything should just start
working automatically with 64-bit time. It will also let us drop the
__fixup hacks in arch/x32/syscall_arch.h and
src/thread/x32/syscall_cp_fixup.c, analogous to how commit
01ae3fc6d48f4a45535189b7a6db286535af08ca let us drop the corresponding
mips hacks.

Rich