On Tue, Nov 11, 2025, at 16:50, Thomas Weißschuh wrote:
On Tue, Nov 11, 2025 at 04:07:58PM +0100, Arnd Bergmann wrote:
On Tue, Nov 11, 2025, at 15:46, Thomas Weißschuh wrote:
On Tue, Nov 11, 2025 at 03:19:00PM +0100, Arnd Bergmann wrote:
On musl there is no SYS_clock_getres_time64 but instead there is SYS_clock_getres_time32.
Right. While this makes a lot of sense conceptually, it also makes it harder to do anything portable based on those macros.
I have been wondering whether the kernel should do something similar and replace __NR_clock_getres with __NR_clock_getres_time32 etc on 32-bit architectures unless a user specifically asks for the compatibility macros. This would help avoid problems with old source code using the traditional macros in combination with the libc data structures. Unfortunately any change here also causes new problems.
Switching to __NR gives us back the more natural fallback logic. We are back at the nolibc 64-bit time functions. We can add a static_assert() to gain some compile-time safety.
static int syscall_clock_getres(__kernel_clockid_t clockid, struct __kernel_timespec *res) { #ifdef __NR_clock_getres_time64 return syscall(__NR_clock_getres_time64, clockid, res); #else /* * __NR_clock_getres expects __kernel_old_timespec. * Make sure the actual parameter is compatible. */ _Static_assert(sizeof(struct __kernel_old_timespec) == sizeof(*res)); return syscall(__NR_clock_getres, clockid, res); #endif }
And stick all of those wrappers into another helper header.
Ok, sounds good.
Arnd