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
