> -----Original Message-----
> From: Miroslav Lichvar <mlich...@redhat.com>
> Sent: Thursday, October 29, 2020 10:24 AM
> To: Richard Cochran <richardcoch...@gmail.com>
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH RFC 0/1] Introduce inclusive terminology
>
> On Thu, Oct 29, 2020 at 09:53:42AM -0700, Richard Cochran wrote:
> > On Thu, Oct 29, 2020 at 11:58:41AM +0100, Miroslav Lichvar wrote:
> >
> > > That wouldn't work well, but as phc2sys doesn't use PTP to synchronize
> > > the clocks, I think it can use a different terminology than ptp4l. It
> > > might actually be less confusing. In the current code the same clock
> > > is master and slave at the same time in different contexts.
> >
> > So how about using client/server in the context of the PTP and
> > source/sink in phc2sys and ts2phc?
>
> Yes, I think I would prefer that over source/sink everywhere. To me,
> server and client are network-related terms, something implementing a
> network protocol, which in context of PTP has a single clock. Sink and
> source work as more general terms. As an adjective of a clock, "source
> clock" works well, but "sink clock" sounds weird to me. I found this
> term in some DisplayPort and HDMI documentation. Maybe it's alright, I
> don't know. Native speakers should give you a better feedback or
> suggestions.
If we used "time source" and "time sink", but that wouldn't include clock in
the name.
What about "target clock"?
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
