Am 11.01.21 um 22:30 schrieb Jacob Keller:
On 1/11/2021 9:05 AM, Richard Cochran wrote:
On Mon, Jan 11, 2021 at 10:07:41AM +0100, Miroslav Lichvar wrote:
What will happen with the "grandmaster" term? Does it stay, or should
No decision yet on that one.
it be replaced with something like "Primary time server"?
That sound reasonable to me.
My only concern is the risk that the next standard will use a
different terminology and linuxptp users will have have to go through
the transition twice.
I think I agree with Richard that much of the things we're renaming
don't strictly have to match. Plus, if we are able to influence the
standards towards this terminology we can avoid the potential.
We can choose the terminology we like without causing confusion. In
fact, thanks to your insight of differentiating server/client and
source/sink, this project will have clear and helpful documentation!
The *only* things we'll have to adapt to the new standard (if and when
it ever appears) are the log messages that include port states. Those
will optionally follow the new terminology. For now, I'm keeping
almost all log messages unchanged, because some users are surely have
scripts that scrape through the logs.
That is correct, log messages are an interface to the outer world. We
must take care of *not* to *force* customers to change their outer
world, when *we* decide to change the [linux-]ptp world.
Right. We can worry about changing those once standards have caught up.
I also think it's important to use the correct terms for various states
and other standard-specific names when possible (much like how you keep
some of the standard names the same even if they do not follow coding
guidelines such as camel casing or not)
What about making log messages configurable? Kinda:
log_role_style traditional
-or-
log_role_style modern
-or-
log_role_style ieee_xyz
This way,customers can switch to the new terminology when *they* are
prepared to do so, and we can prepare the switching when we are not in a
hurry.
The performance impact would be at most an additional computation of an
"%s" format-string per log-message (where appropriate).
Kind regards,
Peter
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
