That's what I understood your comment was about.
Are you saying that's not possible on arm, because the current timer rundownAh, I think you're talking about something else.
counter can't be read while the timer is running?
If I were to run a second timer at higher rate for clocksource, but keeping
the 10 ms timer as clock event (could easily do that by using timer D on
Atari Falcon) - how would that improve my timekeeping? Clock events still
only happen 10 ms apart ...
You seem to be talking about what happens when time keeping interrupts
happen.
I'm talking about the resolution of gettimeofday() and the other
interfaces that are used (eg) for packet capture timestamping and
the like - the _user_ visible effects of the timekeeping system.
With the existing implementation, all these have better-than-jiffy
resolution - in the case of RPC, that's 500ns, rather than 10ms
which would be the case without gettimeoffset(). Removing
gettimeoffset() as Finn has proposed without preserving that
resolution is simply completely unacceptable.