[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jul 2019 01:18:32 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Final (?) time64 proposal
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
