Hi Richard,
> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Thursday, October 10, 2019 10:11 PM
> To: Y.b. Lu <yangbo...@nxp.com>
> Cc: Rodney Cummings <rodney.cummi...@ni.com>;
> linuxptp-devel@lists.sourceforge.net; rodney.greenstr...@gmail.com;
> Андрей Иванов <ia...@yandex.com>; Erik Hons <erik.h...@ni.com>
> Subject: Re: Re: [Linuxptp-devel] [Linuxptp-users] How do I implement Sync
> message receive timeout according to Automotive and 802.1 AS profiles?
>
> On Thu, Oct 10, 2019 at 03:38:28AM +0000, Y.b. Lu wrote:
> > May I confirm that we don't have to use new clock types for PTP End
> Instance and PTP Relay Instance?
> > PTP End Instance should be OC tyoe,
>
> The end instance is already implemented. Why change it now?
[Y.b. Lu] Sorry, I didn't mean to change it now.
Initially I thought that end instance was different with OC. Current end
instance of linuxptp was totally an OC without utilizing follow_up_tlv and free
running clock.
I thought 802.1AS should use free running clock for efficiency, and maybe
application APIs are needed to be implemented.
But now I understand current end instance of linuxptp is conformant to 802.1AS.
Although it doesn't support free running clock, we don't have to support it now
to make it totally same with standard.
>
> > and PTP Relay Instance should be developed based on BC?
> >
> > I had a slovenly PRI/TAB implementation based on P2P TC. If so, I need to
> rework the implementation based on BC, and clean up code before sending
> out for review.
>
> You have two choices:
>
> 1. invent a new clock_type with its own .c and .h file 2. adapt one of the
> existing clock_types
>
> The correct choice depends on the nature of the changes needed. On the one
> hand, if all that is needed is a one-liner, then #2 is the obvious choice.
> On the
> other hand, if the changes mean sprinkling
>
> if (my_special_case) { do_my_special_stuff(); }
>
> everywhere, then #1 makes sense.
>
> In any case, it is hard to guess without seeing your code. Why not post what
> you have done already as an RFC?
[Y.b. Lu] Thanks for your suggestion. We have project called OpenIL
https://openil.org
And my code was on https://github.com/openil/linuxptp
My implementation was immature and was an non-GM time-aware bridge based on
p2p_tc.
Since the patches are not cleaned up and include much redundant code like
timecounter I mentioned for maintaining gPTP time, it's hard for reviewing.
I have sent out a clean RFC patch for review. But the implementation based on
p2p_tc is indeed not right, as Rodney C's explaination.
Thanks.
>
> Thanks,
> Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
