On Fri, 29 Jul 2022 at 18:24, Michalik, Michal <michal.micha...@intel.com> wrote:
> Hello Greg, > > Much thanks for your valuable input - we appreciate it a lot. > Please see my answers inline. > > Have a great day, > MichaĆ Michalik > > > As I highlighted earlier, I, along with other users of ptp4l, don't feel > the linuxptp project is the right place for the submission of the ITU-T > ESMC Protocol (which is based on recommendations G.8274 & G.781). There are > no dependencies on ESMC with the 1588 protocol or the Linux PHC, nor is the > linuxptp maintainer wanting to be a bottleneck for contributions to the > ESMC protocol (as highlighted below from Richard). > > If you don't mind, please let me ask you a question - I am definitely > missing > something. Whom are you talking about while using expression "along with > other > users of ptp4l"? To my best understanding right now we have a situation, > where: > - you are against including it into linuxptp, > - Miroslav Lichvar is for including it, > - Erez is for including it, > I did not suggest it. I do not oppose adding the new tool to the linuxptp project. But it is Richard's call. - if I understand Richard communicate well, he did not say firm "no" - just > raised > some concerns about his bandwidth, > - we (as Intel) are good with both ways - we just need to know. > In which point my understanding is faulty? > > Richard - since you obviously have the last word, would you mind to state > your > final decision clearly to avoid any further interpretations of your answer? > > > > > >My main concern is the fact that my time is limited to work on > >linuxptp, and I already have a back log of patches. If synce will have > >rapid development, new features, etc, then I don't want to be the > >bottleneck. > > > > 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. The implementation not only addresses > the ESMC protocol per G.8264, but also includes some additional features > from G.781. We realize there will be a need to provide QL and other > information from synce4l to ptp4l, per applicable ITU-T 1588 Profiles, and > look forward to collaborating with the linuxptp community to produce these > interfaces. > > Since working in community should be based on honesty, let me be honest > here. > I feel we have a little awkward situation we need to solve somehow > together. > Some facts about the issue I'm thinking about: We have pushed first > patches of > synce4l to linuxptp newsletter on 26th May. Then we see that Renesas have > pushed > one initial commit with only empty README mentioning the synce4l name > (8th Jul) > and second commit with full code implementation (15th Jul) - both commits > were > uploaded few weeks after our initial submission using synce4l name. I am > perfectly aware that neither of us has any trademark rights to the name, > so > technically Renesas did nothing wrong. Still, we feel a little bad about > the > situation where we wanted to be fair and waited for final linuxptp > community > decision before pushing the synce4l somewhere else and in the meantime see > other project started with the same exact name. Let me be perfectly clear > here > - I assume no bad intentions, we just have had a unfortunate coincidence > here. > I assume you also have been working on this application for months and > this > rush in publishing it means absolutely nothing. Let me now explain why > this > name matters for us. We've been using this name internally for some time > now > - it would be quite tiresome to change it in lots of documentation and > communication. Additionally, caring for best quality of our submission to > linuxptp - we have dropped our customers an early sample of synce4l last > year > so they could provide us with a valuable feedback on what we could > improve. > Our customers are familiar with the name synce4l and seeing other project > named > the same might confuse them. Kind question - would you please at least > consider > changing a project name at this very early stage? > > Before you answer that - please let me state our position. We are all part > of > community and sometimes we need to find a solution somehow acceptable to > all. We > are definitely open to changing our application name (within or outside > linuxptp > project), even knowing that it would bring quite a big amount of > additional work. > > Btw. We also considering contributing your project, if that gets more > traction > and would at some time look more promising. What I am concerned about > right now > looking at it, it seems really hardware specific. We aimed to avoid that > at all > cost - our application is not connected to Intel HW at all - it can be > used with NIC of > any vendor. Are Renesas eventually is going to do the same? > > > > > We will also be working with the Network Time Foundation to see if they > would be willing to oversee synce4l project like the other Linux projects > they already manage, including linuxptp. We have also already shared > synce4l project with other MAC/PHY/SoC vendors looking for an ESMC protocol > solution. > > I understand - maybe a good idea is that both Intel and Renesas should > change > the name, so we would not confuse anybody about 'which synce4l is which'? > > > > > Regards, > > Greg > > > > Greg Armstrong > > Principal System Architect, Timing Products Division > > Renesas Electronics Canada Limited > > Mobile: 1-613-218-9373 > > >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel