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

Reply via email to