Background: earlier this year I posted this message about how to wait
until phc2sys and ptp4l are synchronized within a given margin:
https://www.mail-archive.com/linuxptp-users@lists.sourceforge.net/msg02121.html

and it seemed that there wasn't a good solution available for my needs,
but I didn't have time to work on one either.

In the meantime I was forced to write a kernel selftest to prove that a
certain TSN feature works:
https://patchwork.kernel.org/project/netdevbpf/cover/20210930075948.36981-1-xiaoliang.yan...@nxp.com/#24498755
and I was so annoyed about the way in which I need to check for sync
status, that I said to myself I'll write up a C program the first chance
I have.

A week later I managed to find a few free hours to satisfy my selfish
needs, and here I am presenting the idea to the list for initial feedback.

I would really like linuxptp to have something like this going forward,
it really helps automation scripts to have consistent results with few
lines of shell code. I understand there might be items we need to
discuss about more (like allowing remote PMC subscriptions, how to do
that safely) and that's one of the topics that the discussion should be
about. I thought that simply adding a bool config option would be enough
precaution for now.

The other topic is how to actually wait for phc2sys to synchronize,
since the program presented here only works with ptp4l (or at least
that's all I tested). We would need to generalize the clock management
API into something that is embeddable in the struct clock used by
phc2sys (because yes, phc2sys uses a "struct clock" that isn't the same
"struct clock" as ptp4l). Richard suggested in the first link that we
could let the "struct clock" from ptp4l receive the subscription
requests and just have a special case for portIdentity.portNumber = 0xffff,
those messages could be forwarded to the local phc2sys over UDS.
With push notifications I do believe that becomes a bit more
complicated, because the local ptp4l would also need to forward the push
notification events back, and I don't know right now if that is the best
overall design or if we can do better.

Vladimir Oltean (10):
  pmc_agent: allow subscribing to TIME_STATUS_NP events
  pmc_agent: allow instantiating over other transports than UDS
  pmc_agent: add a function to retrieve clock identity
  util: make cid_eq comparisons take a const pointer
  clock: optionally allow remote subscriptions
  pmc_agent: make pmc_agent_query_port_properties take an enum
    port_state argument
  config: make boundary_hops a config item
  pmc_agent: print management error code values
  util: make pid2str and cid2str take const pointer arguments
  checksync: new program to wait for a local or remote clock to
    synchronize

 checksync.c | 577 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 clock.c     |  22 +-
 config.c    |   2 +
 makefile    |   8 +-
 phc2sys.c   |  12 +-
 pmc_agent.c |  66 +++++-
 pmc_agent.h |  28 ++-
 ts2phc.c    |   7 +-
 util.c      |   8 +-
 util.h      |   7 +-
 10 files changed, 704 insertions(+), 33 deletions(-)
 create mode 100644 checksync.c

-- 
2.25.1



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

Reply via email to