On Thu, Dec 07, 2017 at 12:58:16PM +0000, Rommel, Albrecht wrote: > Ideally, the UDS port meets the requirements of a "virtual PTP port" as > defined in ITU-T G.8275.
> A virtual PTP port supports all attributes as normally transported > in Announce messages or general PTP headers, except that the timing > information comes via technology proprietary methods, i.e. GPS like > via 1PPS and ToD, instead via packet timestamps. In this context, > having all management, responses, and signaling messages to appear > at a UDS port as it would appear at normal PTP ports, the UDS could > support the IWF between two PTP nodes, which are either configured > for different PTP profiles each, or which are connected via > non-Ethernet (i.e. transport/access technology specific methods). Not sure what you are driving at. The UDS port is for local control only. You can use it to allow a GPS, etc service to talk to ptp4l just fine. The GPS code could care less about Announce messages. We can already run two or more different profiles on two or more different ports. No need to abuse UDS for that. WRT other transports, these should be added in the transport layer. It already supports new methods by its modular design. Thanks, Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
