[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Jul 2019 16:11:07 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: time_t assessment of what needs to be done
Regardless of how we handle ABI, there's some fixed amount of work
that has to be done for actually implementing 64-bit time_t support on
archs where it was not historically 64-bit, without breaking the
ability to run on older kernels. At least the following interfaces
need to check (via #ifdef on the syscall numbers or or some
syscall_arch.h provided macro) whether there's a time64 version of
their operation, and if so, not only use it, but also check for ENOSYS
or equivalent and fallback to performing conversions and using the old
syscalls:
- clock_gettime
- clock_settime
- clock_adjtime
- timer_gettime
- timer_settime
- timerfd_gettime
- timerfd_settime
- utimensat
- mq_timedsend
- mq_timedreceive
- semtimedop
- clock_nanosleep
- stat
- fstat
- lstat
- fstatat
Then there are some functions that can get by without using the new
syscall at all (avoiding the need for fallback logic), but that need
to convert relative times or such between legacy kernel format and new
userspace format:
- nanosleep
- clock_getres
- sched_rr_get_interval
- pselect
- ppoll
- sigtimedwait
- recvmmsg
- __timedwait
- getrusage
The adjtime function is probably also in this category, but it should
probably just be rewritten not to use the syscall directly, but in
terms of clock_adjtime. Same for adjtimex.
Next, for these functions:
- setsockopt
- getsockopt
- ioctl
there are also affected commands, at least:
- SO_TIMESTAMP
- SO_TIMESTAMPNS
- SO_TIMESTAMPING
- SO_RCVTIMEO
- SO_SNDTIMEO
For these we need to change the macro numbers to the new 64-bit ones,
and provide fallback code so that, if the kernel doesn't recognize the
new command, it's retried with the old one and conversion.
Finally, the sysvipc stuff is the worst. These functions require
decoding endian-swapped time_t values or bits stuffed into
reserved/padding areas of the legacy structs into whatever new
application-facing structs we use:
- shmctl
- semctl
- msgctl
It's not clear to me if glibc has decided (or even started on) new
layouts of the affected structs (shmid_ds, semid_ds, msqid_ds). Since
keeping ABI-compat is desirable, we should figure this out asap.
A few misc issues I also found:
The utmp structure has just enough reserved space to move ut_tv to the
end and make it unconditionally 64-bit-time_t. This is also nice for
mixed 32/64-bit systems. Of course musl's utmp stuff is nopped out
anyway but the types should be fixed for users of third-party utmp
tooling/libraries. Alternatively we could just change it, since it's
not an app-libc ABI at this point as far as I can tell. Matching the
current 64-bit layout might be more useful than changing both.
And.. sys/procfs.h has soem timevals in struct elf_prstatus. I'm not
sure if this is on-disk ABI, if so with what, and whether it's even
used anymore anyway. This probably needs to be investigated. I'd love
to rip it out if it's not needed.
And.. sys/timex.h has struct ntptimeval with a legacy timeval inside.
There don't seem to be any libc interfaces that use it, but maybe
something else does...
Now, back ot ABI. In addition to the above mentioned functions, the
following also have time_t or derived types in their interfaces, but
don't depend on syscalls, only on other underlying functions that
would already accept the userspace time_t/timeval/timespec form:
- pthread_mutex_timedlock
- pthread_cond_timedwait
- pthread_rwlock_timedrdlock
- pthread_rwlock_timedwdlock
- sem_timedwait
- mtx_timedlock
- cnd_timedwait
- thrd_sleep
- sleep
- time
- gettimeofday
- settimeofday
- difftime
- mktime
- gmtime
- localtime
- ctime
- gmtime_t
- localtime_r
- ctime_r
- stime
- timegm
- utime
- ftime
- utimes
- futimes
- futimesat
- lutimes
- futimens
I may have missed some; that list was built by grepping headers
casually.
If doing the ".2 ABI", no action would be needed on these; they just
automatically switch over. If we do the transition that avoids forcing
a hard ABI switchover, these as well as all the earlier-mentioned
functions will need header-level redirects, and legacy wrappers to
satisfy references to the legacy functions. By my sloppy count, that's
about 60 redirects/new-symbols, not horrible, but probably a little
bit more than I expected.
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.
