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
