> But my point was to use the actual binary management TLVs, i.e. the > messages that pmc turns into text.
I don’t follow this. How would my script get access to the management TLVs? It sounds like you’re suggesting that I reimplement PMC in my own application? > On 22 Jul 2020, at 23:16, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, Jul 22, 2020 at 02:14:48PM +1000, Luke Howard wrote: >> [resending from correct email] >> >>> The output of the pmc tool is still unstructured text. So to feed it into a >>> script I would still need to write an output parser of some sort and I >>> would have to guess that my parser covers all of the cases that the tool >>> might generate and I would have to assume that the output format doesn’t >>> change. This is what got me thinking about structuring the output format >>> somehow in a way that any tool could consume it. >> >> Perhaps in that case a structured text option to pmc(8) would be useful and >> not too hard to add? > > In contrast to the logging, I think the pmc output is already > structured and easy to parse. > > But my point was to use the actual binary management TLVs, i.e. the > messages that pmc turns into text. > >> You can access the management interface remotely I believe, although I don’t >> know anything about the authorisation model. > > Yes, it works remotely, but IEEE 1588 does not specify an > authorization model. The ptp4l programs allows queries from the > network unconditionally, but setting (changing) any value requires > local access via UDS. This, in turn, can be opened to remote > operators by using ssh. > >> Also a bit of googling of SNMP and PTP also turned up these: > > The SNMP is another can of worms, and it isn't implemented here. > > Thanks, > Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
