From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14338 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: time_t assessment of what needs to be done Date: Mon, 1 Jul 2019 16:11:07 -0400 Message-ID: <20190701201107.GA6060@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="254733"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14354-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 22:11:25 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hi2e1-00146v-FR for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 22:11:21 +0200 Original-Received: (qmail 32523 invoked by uid 550); 1 Jul 2019 20:11:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32491 invoked from network); 1 Jul 2019 20:11:19 -0000 Content-Disposition: inline Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14338 Archived-At: 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