On Wed, Mar 04, 2020 at 08:49:45AM -0800, Richard Cochran wrote: > On Mon, Feb 17, 2020 at 01:46:26PM +0100, Miroslav Lichvar wrote: > > On Mon, Feb 17, 2020 at 02:34:14PM +0200, Heikkinen, Ville (Nokia - > > FI/Espoo) wrote: > > > (https://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf). In > > > there, it's specified that "STA_UNSYNC set/cleared by the caller to > > > indicate > > > clock unsynchronized (e.g., when no peers are reachable)". So, this is the > > > reasoning why the flag could be used like this. > > > > Good find. > > > > FWIW, I'm not aware of any software that would unset the flag when the > > you meant, "set", right?
Right. > > > clock stops being updated. That includes software that was maintained > > by Dr. Mills. > > > > It seems wrong to me to do that, but I'm not strongly opposed. > > I think we can go ahead and give a flag a meaning. If the kernel > meant to enforce some other kind of meaning, then it would have had to > check the value that user space provides. I'd stick with the meaning "the clock has is believed to have an error larger than 16 seconds". With ptp4l/phc2sys, if someone needs to check if the clock was updated in the last X seconds, they can check the maxerror value if it's not larger than X * 500us. No need to set the UNSYNC flag. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
