On Thu, Nov 30, 2023 at 07:12:54PM +0100, Andrew Zaborowski wrote:
> On Thu, 30 Nov 2023 at 17:44, Richard Cochran <[email protected]>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
