On Tue, Nov 18, 2025 at 10:40:03PM +0100, Arnd Bergmann wrote:
On Tue, Nov 18, 2025, at 15:22, Thomas Weißschuh wrote:
On Fri, Nov 14, 2025 at 11:40:31AM +0100, Arnd Bergmann wrote:
On Fri, Nov 14, 2025, at 11:02, Thomas Weißschuh wrote:
On Fri, Nov 14, 2025 at 10:16:01AM +0100, Arnd Bergmann wrote:
I don't think it is important. For my SPARC vDSO series I even dropped the regular clock_getres() after your request. But because it doesn't exist we need to handle the presence of vdso_clock_getres() and the simultaneous absence of sys_clock_getres() in the test.
But that is the other way round, right? On sparc32 we have (optionally) sys_clock_getres() but never vdso_clock_getres().
Here SPARC was just an example to show that I don't really care about clock_getres() in the vDSO in general. But if it was present before for an architecture and we now drop it without a replacement, userspace developers might complain. Manually caching the value in userspace sounds ugly and brittle, as it could even change at some point. Introducing a time64 replacement on the other hand wouldn't make much difference as the values never would exceed the 32-bit range anyways.
So I would keep vdso_clock_getres() where it exists today even with CONFIG_COMPAT_32BIT_TIME=n.
It is rather inconsistent with all the other interfaces though: when we originally did the time64 conversion, there were a number of interfaces that didn't really need a replacement, but we deliberately made new interfaces wherever possible. For architectures without time32 support, and for validating the time64 support, it should be possible to build both kernel and userspace without even defining the __kernel_old_time{_t,spec,val} types.
Fair enough. I'll add this to my TODO list.
Right, but then I would make it return 'struct timespec', not 'struct __kernel_timespec', because it's no longer the kernel interface.
(...)
Thomas