[S] Change in flashrom[main]: udelay: clock_getres() does not provide clock_gettime() resolution

[Brian Norris (Code Review)]

Attention is currently required from: Anastasia Klimchuk, Nikolai Artemiev, Stefan Reinauer.

Brian Norris has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/80806?usp=email )

Change subject: udelay: clock_getres() does not provide clock_gettime() resolution
......................................................................

Patch Set 2:

(2 comments)

Commit Message:

https://review.coreboot.org/c/flashrom/+/80806/comment/a24825da_d6cc7b52 :
PS2, Line 10: Linux makes this clearer
> Brian, thank you for the work on this! And you even looked through old forgotten patches! […]

It's a good question, and my answer is that I'm not sure. I never found the POSIX descriptions to be super precise here, but Linux docs seem to suggest that the Linux decisions are somewhat diverged from POSIX. So it's possible some POSIX-like system has different ideas of resolution and of clock_gettime() behavior.

How would you like me to proceed with this question? Make educated guesses? (e.g., seems N/A on Windows; MacOS might be in [1]; ...) Or carve out `#ifdef __linux__` behavior here?

Regarding guesses: I see that MacOS claims microsecond precision for CLOCK_MONOTONIC; and CLOCK_REALTIME seems less clear (possibly more-precise). So it's possible this is a regression for Mac.

[1] https://opensource.apple.com/source/Libc/Libc-1439.141.1/gen/clock_gettime.c...

https://review.coreboot.org/c/flashrom/+/80806/comment/4694382e_5b4cfced :
PS2, Line 42: https://review.coreboot.org/c/flashrom/+/39864
            : https://review.coreboot.org/c/flashrom/+/44517
> In your opinion, if your patch goes ahead , are these old patches still needed?

I suppose that depends on the underlying motivation and use case there.

I assume that such patches are simply trying to reduce the time wastage in "calibration". If that's all that it is, and they're using a reasonable POSIX-like system, then no, they won't be needed.

If such developers have systems that really can't use clock_gettime() for some reason (e.g., I think Windows + mingw won't have clock_gettime() at all? I don't have anything to test this with), then yes, they could still technically be desirable.