On 11/9/2020 8:14 AM, Richard Cochran wrote:
> On Mon, Nov 09, 2020 at 10:12:58AM +0100, Miroslav Lichvar wrote:
>>
>> Makes sense to me, but maybe it's time to drop the workaround? Looking
>> at the git log, it was added in 2013. Are people still using linuxptp
>> on kernels older than that?
>
> Yes, I think so.
>
> When I was collaborating with Balint on his ts2phc not too long ago,
> someone from Intel was asking to please make sure it still works on
> Linux v3.0.
>
> Thanks,
> Richard
>
I know we get requests and reports from a few folks who end up sticking
to the same release for a long time.
If we were going to change where LinuxPTP is supported, I think we would
want to do so in some staged manner where we produce deprecation
warnings in one release indicating that support will be dropped for
older kernels, and only drop support in a later release after we've
given some time for folks to (hopefully) be made aware of this fact.
Of course, we should weigh the cost of maintaining the code vs the cost
of headaches when someone uses the program and it doesn't work quite
right. Special care should be taken when failure is non-obvious, and the
application doesn't fail immediately when it isn't working.
In this case, the issue is that our attempt to read the frequency may
not give us valid results. If it fails, then we'll mistakenly assume an
incorrect frequency. This will cause the programs calculations of
frequency drift to be incorrect, resulting in non-optimal adjustments
especially early on. Because this type of failure does not result in an
immediate and obvious failure, I think we ought to be more careful in
handling this work around.
Thanks,
Jake
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
