Re: [PATCH 5/5] [DO NOT MERGE] timekeeping: Apply extrapolated ntp_error to clock snapshots

[David Woodhouse]

On 5 October 2026 12:15:27 CEST, Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote:
>> As a parallel thread I'll also look at unconditionally using the
>> existing (non-correcting) ktime_get_snapshot_id() so that we have the
>> corresponding counter values, and an ioctl for reporting those to
>> userspace alongside the ts_real. I am leaning towards using raw counter
>> values even when an offset has been applied to the realtime value, but
>> still vacillating a bit.
>
>Raw counter values get my vote: userspace set the offset itself with
>PPS_SETPARAMS, so it can apply it to the counter if it needs to, while
>the counter should stay the value actually read from the hardware. :-)
>
>AFAIK that's also what the kernel consumer gets today: pps_kc_event() is
>passed the timestamp before the offset is added, isn't it?

Think so, yes. Although I'm going to think about that too. The GNSS module can tell us the expected offset (from top of second) of the upcoming pulse, and the kernel *should* consume that.

I'm going to play with a dæmon which feeds the kernel the offset for the next pulse, each second.

>When you get to the ioctl, please post it as an RFC before the code.

Ack. And we can finally kill that 32-bit alignment thing that the header file says I pointed out when PPS was first merged :)