NTP client recommendation for RTEMS?
Joel Sherrill
joel at rtems.org
Fri Feb 18 14:39:12 UTC 2022
On Fri, Feb 18, 2022 at 7:46 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> On 18/02/2022 14:43, Joel Sherrill wrote:
> > On Fri, Feb 18, 2022, 7:22 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >
> > Hello,
> >
> > I would like to add an NTP client support for RTEMS. The ntp_adjtime()
> > implementation is already available as a patch. For testing purposes I
> > ported the NTP daemon from FreeBSD to libbsd. This basically works
> > fine.
> > I am not sure about the maintenance status of this code
> > (https://www.ntp.org/ <https://www.ntp.org/>). There is also
> >
> > https://www.ntpsec.org/ <https://www.ntpsec.org/>
> >
> > This project has a public Git repository and seems to be more active.
> > However, there is no standard package for openSUSE Leap 15.3. Maybe
> > this
> > is because most Linux users use now timesyncd from systemd. Any
> > recommendations?
> >
> >
> > I'd stick with ntp.org <http://ntp.org> without much thought. With that
> > being what FreeBSD uses, it is icing on the cake.
>
> The code looks not that good. There seems to be a lot of cleanup done in
> ntpsec.org.
Yes that is true. And I will communicate my concerns offline. One of
the main ones is that the ntpsec project was heading in a very Linux
centric way on what APIs would be used. They did kill a lot of old platforms
and do some clean up which is good.
There were discussions about re-writing it in Go. If that happens, we
would have issues.
In general, I leaned to the freebsd.org code because we already have
a process in place for dealing with it. And if it is good enough for FreeBSD,
it should be a good first choice for us.
If this turns out to be wrong, there is ntpsec and OpenNTP which seem
to be derived from ntp.org. Any porting done on the freebsd.org code should
apply to the others easily enough.
No idea what to do about a full NTP client for lwip. Any thoughts?
>
> >
> > Did you eliminate use of signals like Chris had to do with ptpd?
>
> Not yet, they use both select(), but this should be changed to use
> kqueue(). I hacked away the use of signal.
Great! Is this work going to land in the public in the near future?
--joel
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list