[Linuxptp-users] phc2sys: why set CLOCK_TAI offset only when UTC offset is traceable?

[Vladimir O. <ol...@gm...>]

phc2sys sets the CLOCK_TAI offset of the kernel since commit

commit fefd5b4b05039ea0a0770291b12b0eb931079970
Author: Miroslav Lichvar <mli...@re...>
Date:   Wed Jun 18 15:44:49 2014 +0200

    Set TAI offset of system clock.

    When synchronizing the system clock and the PTP UTC offset is valid and
    traceable, set the TAI offset of the clock to have correct CLOCK_TAI
    (which is implemented in the kernel as CLOCK_REALTIME + TAI offset).

    Signed-off-by: Miroslav Lichvar <mli...@re...>

What I'm missing is:

1. ptp4l in the role of a GM appears to listen for GRANDMASTER_SETTINGS_NP
   PTP management messages on the local r/w UDS socket and that's how it
   updates its ANNOUNCE message contents. Who is supposed to construct and
   send these PTP management messages to the ptp4l GM in a "normal" system?

2. In the case of a slave clock, phc2sys detects that the UTC offset of
   the GM is traceable, and updates the CLOCK_TAI offset in the kernel.
   But for the GM system, who is supposed to update the CLOCK_TAI offset?
   There is some logic in clock.c, namely clock_utc_correct() called
   from clock_synchronize():

	/* Update TAI-UTC offset of the system clock if valid and traceable. */
	if (c->tds.flags & UTC_OFF_VALID && c->tds.flags & TIME_TRACEABLE &&
	    c->utc_offset_set != utc_offset && c->clkid == CLOCK_REALTIME) {
		sysclk_set_tai_offset(utc_offset);
		c->utc_offset_set = utc_offset;
	}

   but mind you, c->clkid is only set to CLOCK_REALTIME if we are
   performing software timestamping. So in the general case, ptp4l as GM
   does not update the CLOCK_TAI offset, and phc2sys does not, either.

3. Finally, why update the kernel's CLOCK_TAI offset only if the UTC
   offset is traceable? I mean, phc2sys in automatic mode sets up the
   CLOCK_REALTIME apart by 37 seconds from the PHC anyway, regardless of
   whether the UTC offset is traceable or not. Would it not make sense
   to set the kernel's TAI offset regardless? As things stand, I think
   this behavior is just highly inconsistent. CLOCK_REALTIME certainly
   has an offset from the TAI timescale, as set by phc2sys, but
   applications cannot detect this.