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
