Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock

[Thomas Gleixner]

On Thu, May 21 2026 at 22:06, David Woodhouse wrote:
> On Thu, 2026-05-21 at 20:30 +0200, Thomas Gleixner wrote:
>> 
>> As I said in the other thread, that's just creating yet another private
>> mechanism instead of collecting the counter value together with e.g.
>> CLOCK_REALTIME 
>
> On the plus side, at least he wasn't providing a counter value at *all*
> for the system timestamps, which is better than using a bogus one :)

At least ... for now :)

> Can we have a signed-off-by for your ktime_get_snapshot_id() please?

Are you kidding? That's a PoC to demonstrate how it should be done and
it needs some thought to implement it correctly along with the
get_device_cross_timestamp() one, which is actually not entirely
correct as I noticed a few minutes ago.

>> or utilizing the PMT correlated one which is available in
>> get_device_crosstime_stamp().
>
> AFAICT that was the *only* one he was exposing, wasn't it? The vmclock
> driver literally did expose the cycle count used to create the device
> timestamp, which is equivalent to PTM and looked correct for that
> part?

The vmclock driver lives in it's own made up world, so yes this looks
consistent on the first glance.

Thanks,

        tglx