On Wed, 2022-12-07 at 06:59 -0800, Richard Cochran wrote: > On Thu, Nov 17, 2022 at 02:15:23PM -0800, Jacob Keller wrote: > > On 11/17/2022 1:34 PM, Geva, Erez wrote: > > > > The problem is the fallback works only on build. > > > But if the build system is newer than the running system, the > > > fallback > > > will fail, as you will use the PTP_CLOCK_GETCAPS2 which does not > > > exist > > > on the running old system. > > > > > > > Fair. We likely have the same problem with some of the other "2" > > ioctls, > > since they're handled in a similar way. I think we do the Right(TM) > > thing > > for the sysoff.c where we probe the kernel at run-time. This could > > be done > > here but is probably not really worth it considering that > > PTP_CLOCK_GETCAPS > > functions the same way as PTP_CLOCK_GETCAPS2 for all kernels I > > checked... So > > I guess this is somewhat less likely. > > Jacob, do you want to have phc_ctl fall back to PTP_CLOCK_GETCAPS at > run time if PTP_CLOCK_GETCAPS2 fails?
We can use run-time fallback. But personalty, I do not think it worth it. Using PTP_CLOCK_GETCAPS2 is only done for one new field in a debug tool. We can simply wait till PTP_CLOCK_GETCAPS become obsolete or we have a new PTP_CLOCK_GETCAPS3 to handle. > > > I'm not sure if our other PTP ioctls are checked properly like this > > at run > > time... > > Maybe, but only because of sloppiness. Better to support older > kernels at run time, as this is more user friendly. > > Working on embedded systems over the years, I've have often been that > user, and, believe me, it is super annoying when the latest greatest > App isn't backwards compatible. My view too :-) > > Thanks, > Richard Erez _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
