Re: [patch V3 04/11] timekeeping: Provide time setter for auxiliary clocks

[Thomas Gleixner]

On Fri, Jun 27 2025 at 16:18, Thomas Gleixner wrote:

> On Thu, Jun 26 2025 at 21:23, John Stultz wrote:
>> On Wed, Jun 25, 2025 at 11:38 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>>>
>>> Add clock_settime(2) support for auxiliary clocks. The function affects the
>>> AUX offset which is added to the "monotonic" clock readout of these clocks.
>>>
>>> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>>> ---
>>
>> Minor fretting: I worry a little that the difference here between the
>> default timekeeper where set adjusts the REALTIME offset from
>> MONOTONIC, and here where it directly adjusts "mono" might confuse
>> later readers?
>
> Actually it's not really that different.
>
> In both cases the new offset to the monotonic clock is calculated and
> stored in the relevant tk::offs_* member.
>
> The difference is that the core timekeeper operates on xtime, but for
> simplicity I chose to calculate the resulting tk::offs_aux directly from
> the monotonic base. That's valid with the aux clocks as they don't
> need any of the xtime parts.

Actually using xtime and adjusting it and xtime_to_mono does not work
for those auxiliary clocks because the offset to clock "monotonic" is
allowed to be negative, unless it would result in a overall negative
time readout.

This is required for those clocks because the TSN/PTP zoo out there
especially in automation/automotive uses clockmasters starting at the
epoch for their specialized networks. So if the clockmaster starts up
_after_ the client, then the pile of xtime sanity checks would prevent
setting the clock back to the epoch.

I tried to work around that, but the result was more horrible and
fragile than the current approach with the aux specific offset.

Don't ask :)

Thanks,

        tglx