Re: [Linuxptp-devel] [PATCH 0/3] Convert to inclusive terminology, Part III

2021-01-19 Thread Keller, Jacob E



> -Original Message-
> From: Richard Cochran 
> Sent: Monday, January 18, 2021 10:57 AM
> To: linuxptp-devel@lists.sourceforge.net
> Subject: [Linuxptp-devel] [PATCH 0/3] Convert to inclusive terminology, Part 
> III
> 
> * Part III
> 
>   - Mark the existing masterOnly option as deprecated, providing an
> alternative option called serverOnly.
> 

This part looks good to me.

Reviewed-by: Jacob Keller 

> * Background
> 
> There is an industry wide effort underway to replace historically and
> culturally loaded terms like master/slave with neutral alternatives.
> The IEEE 1588 committee will most likely amend the standard, but so
> far no consensus on the new terminology has been reached.
> 
> Many of the proposed alternative terms are either awful sounding or
> just plain silly.  This project will take the lead by implementing
> proper English language terminology that is, at the same time, both
> culturally neutral and technically more accurate.
> 
> The original designation of the PTP port roles made little sense in
> the first place.  Under the institution of slavery, the role of a
> slave is to perform work for the master.  In a PTP network it is the
> "master" port that serves the slaves, the opposite of what the terms
> suggest.  Thus, in the context of the PTP port roles, we have chosen
> to replace master/slave with client/server.
> 
> Besides the PTP port roles, there is the area of local clock
> synchronization as performed by the phc2sys and the ts2phc programs.
> In the past we have applied the master/slave terminology in a
> confusing manner.  The phc2sys program labeled a single port both
> master and slave at the same time, but in different contexts.  In
> contrast, the new terminology will be "time source" and "time sink",
> inspired by signal nomenclature from the field of electrical
> engineering.
> 
> Thanks,
> Richard
> 
> 
> Richard Cochran (3):
>   Deprecate the masterOnly option in favor of serverOnly.
>   Convert the example configuration files over to the new serverOnly
> option.
>   Update man page to reflect the new serverOnly option.
> 
>  config.c  | 5 -
>  configs/G.8265.1.cfg  | 2 +-
>  configs/G.8275.1.cfg  | 2 +-
>  configs/G.8275.2.cfg  | 2 +-
>  configs/automotive-master.cfg | 2 +-
>  configs/default.cfg   | 2 +-
>  port.c| 4 ++--
>  ptp4l.8   | 6 +-
>  8 files changed, 16 insertions(+), 9 deletions(-)
> 
> --
> 2.20.1
> 
> 
> 
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


Re: [Linuxptp-devel] GET-only UDS port

2021-01-19 Thread Richard Cochran
On Tue, Jan 19, 2021 at 04:04:39PM +0100, Miroslav Lichvar wrote:
> Or maybe add a separate Unix socket for GET-only operations?

I think this is the way to go.  People will soon want RDWR and RDONLY
on the same system.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel


[Linuxptp-devel] GET-only UDS port

2021-01-19 Thread Miroslav Lichvar
In some environments there is a need to allow other applications to
monitor ptp4l using the UDS port. They are restricted and should not
be able to mess with ptp4l.

Do you think it would make sense to implement a "uds_get_only" option
to disable all non-GET commants?

Or maybe add a separate Unix socket for GET-only operations?

-- 
Miroslav Lichvar



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel