Attention is currently required from: Anastasia Klimchuk, Nikolai Artemiev, Stefan Reinauer.
2 comments:
Commit Message:
Patch Set #2, 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.auto.html
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.
To view, visit change 80806. To unsubscribe, or for help writing mail filters, visit settings.