On Thu, Nov 30, 2023 at 07:12:54PM +0100, Andrew Zaborowski wrote: > On Thu, 30 Nov 2023 at 17:44, Richard Cochran <richardcoch...@gmail.com> > wrote: > > On Thu, Nov 30, 2023 at 04:32:20PM +0100, Andrew Zaborowski wrote: > > > > + PORT_ITEM_STR("cmlds_client_address", "/var/run/cmlds_cleint"), > > > > > > I assume the use of this is simply to set unique names for per-port > > > sockets. Maybe something like tempnam() could be used instead. > > > > No, it has to be under user control, because the path might be under a > > security policy. > > Do you mean that the user might want it to be under a security policy?
Yes. > Otherwise it could be in /tmp. The top down path has to be the user's choice, /tmp/... or /var/run/... or /whatever/... and so there must be a configuration option in any case. It seems silly to restrict the option to the leading path and not include the socket file name. > > > > @@ -1868,6 +1869,33 @@ static void port_clear_fda(struct port *p, int > > > > count) > > > > p->fda.fd[i] = -1; > > > > } > > > > > > > > +static int port_cmlds_initialize(struct port *p) > > > > +{ > > > > + struct config *cfg = clock_config(p->clock); > > > > + struct subscribe_events_np sen = {0}; > > > > + const int zero_datalen = 1; > > > > + const UInteger8 hops = 0; > > > > + > > > > + p->cmlds_port = config_get_int(cfg, p->name, "cmlds_port"); > > > > > > Should this fall back to port_number(p)? > > > > I don't see how, since there is always a default for each > > configuration option. > > Right, it'd need to default to, say, -1 which would be checked here. Okay, sure. That will reduce configuration burden for normal setups. > > Also, I understood from you guys that the port > > number _has_ to be different to pass compliance tests. For that, I > > thought adding a "starting port number" option would do the trick > > The port identity (clock identity + port number) has to be unique. As > long as the clock identity is unique, which it has to be, I don't > think the port number *has* to be different. Got it. > > serviceMeasurementValid is implicit, because if you get a PUSH > > notification, it is valid. > > Right, serviceMeasurementValid == true is implicit but > serviceMeasurementValid == false is useful for the .port_id_valid / > .pdr_missing logic to work. The timeout logic is disabled with > P2P_COMMON. Right, so the next TODO is to enable FD_DELAY_TIMER for P2P_COMMON mode and let it 1) renew the push subscription and 2) catch the case when the push notification does not arrive on time. Thoughts? Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel