>-----Original Message----- >From: Miroslav Lichvar mlich...@redhat.com >Sent: Thursday, August 4, 2022 11:08 AM > >On Wed, Jul 20, 2022 at 03:50:04AM +0000, Greg Armstrong wrote: >> To address this concern, Renesas has submitted our open implementation of >> the ESMC protocol to github, also under the same name: >> https://github.com/renesas/synce4l. This is an open project under GPLv2, and >> we welcome contributions to it. > >I looked at the project to better understand the differences between >this and the Intel implementation. Here are my observations. > >The code doesn't build on its own. It requires "clockmatrix api", >which doesn't seem to be available without registration. > >There are some HW-specific ioctls. > >I don't see an abstraction which would allow one binary to support >different types of hardware. > >About 20% of the code comes from linuxptp (per copyright). > >-- >Miroslav Lichvar >
Thanks Miroslav! I assume that silence on this thread (from the rest of the members), same as silence on any other community mailing list thread, is actually a quiet approval (or at least no one has any objections). Greg, You are saying that your project is open source, and you would welcome contribution to it, but at the same time seems that your code: - requires third party proprietary module for compilation, - uses HW specific i2c to configure your NIC/timecard. Is that true? If so, do you think that it is proper way to cooperate with an open source community? Excuses me but I hardly understand what you would like to achieve except blocking delivery of this solution. As I see it, your only argument is that SyncE is not a part of 1588. Well sure, SyncE is only mentioned in appendices, but you know, Telecom Profiles are not part of 1588, they are only mentioned in appendices. Should support for them be removed from linuxptp? In my humble opinion, it wouldn't make any sense. Maybe SyncE without PTP does make some sense, but for telecoms it makes most sense to use them both (if hardware supports it). Following this idea, it makes most sense to have both in the same package, as for full support of "Annex L" (1588), the SyncE daemon shall provide data to the PTP daemon. It is easiest to maintain both applications in one repository, this prevents any incompatibility issues between shared interfaces. Richard, I know our solution in its current state is far from being perfect. It communicates with EEC by shell commands specified by the user, but at least it is not specific for any particular hardware. Although it doesn't configure EEC, as it shall be preconfigured before using our solution. Our next steps would be: - introduce in-kernel interface which allows control of EEC, - implement a user-space tool for configuration of EEC using new in-kernel interface, - add support for EEC "get lock status"/"set source" in our solution and Replace shell commands - add support for getting EEC info for Telecom profiles in our solution. Could you please decide if there is a room for this solution in linuxptp, assuming we will review and ACK all the future patches on the SyncE part, and help to maintain it as long as it needs support? We are planning to help extending ptp4l with the interface to interoperate with synce4l (and other similar tools, including Renesas implementation). Also, if you think that it would be better to have it in separated project, please let us know, as we need to upstream it somewhere due to customer requests. Thank you, Arkadiusz _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
