Re: [PATCH v2 12/13] sparc64: vdso: Implement clock_getres()

[Thomas Weißschuh]

On Fri, Aug 15, 2025 at 10:09:23PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 15, 2025, at 14:34, Thomas Weißschuh wrote:
> > On Fri, Aug 15, 2025 at 02:13:46PM +0200, Arnd Bergmann wrote:
> >> On Fri, Aug 15, 2025, at 12:41, Thomas Weißschuh wrote:

(...)

> >> On sparc64 kernels, I think you only need the
> >> clock_getres_fallback() for 64-bit userspace, while
> >> the compat path probably doesn't care about getres, neither
> >> the time32 nor time64 variant.
> >
> > Why?
> 
> The clock_getres() vdso call is questionable even on 64-bit
> systems, though we appear to have ended up with one on all
> the major ones. Realistically if an application needs the
> resolution often enough to want a fast way to get it, it can
> just store it in a variable.

Agreed.

> On 32-bit, we decided against adding a clock_getres_time64()
> syscall when we added clock_gettime64() because of this.

My assumption was that clock_getres_time64() wouldn't make sense in the
first place, as no clock would have a resolution this big.

> For time64 userspace, this means that glibc always calls
> the system call instead of the vdso, and old time32
> userspace wouldn't use the clock_getres() vdso because
> there was no vdso implementation when it was compiled.

Is this paragraph meant to be specific for SPARC? Glibc does use the
clock_getres() vdso fastpath on time64 architectures. But on SPARC no
application would ever use clock_getres() through the vdso today,
as it doesn't exist yet.

In any case, I have no strong opinions about this patch and am happy to drop it
or support only SPARC64. Most likely nobody will bother to update glibc anyways.


Thomas