Chris Johns created an issue: https://gitlab.rtems.org/rtems/pkg/rtems-net-services/-/issues/16
Assignee: Chris Johns RTEMS applications need a way of determining if the `ntpd` client has a valid peer and the reported time is synchronized. An example is the EPICS Clock server. EPICS applications can have a number of clock sources and if one is not working it will automatically move to the next in the priority list. The `ntpd` client provides status support via `ntpq` to query the client to get the status of any peers. The RTEMS NTP port provided a working `ntpq` shell command. The `ntpq` query is a UDP packet to `ntpd` and the response is a series of text fields for the peers. This issue is to provide a call RTEMS code can make to get the status of a peer or peers. The issue is the result of a review of the [Add RTEMS ntpd support](https://github.com/epics-base/epics-base/pull/528) pull request to EPICS. The PR adds C string parsing code to the NTP support in EPICS and the review comments related to C string parsing code are valid and need to be addressed. The solution is bring the support to get the peer status into RTEMS Net Services and to provide an interface EPICS can call. We have a couple of options: 1. Take the implementation in the EPICS PR and add it to RTEMS Net Services with unit tests to validate the C string parsing code. 2. Extract the data directly from the peer list list `ntpd` maintains. The NTP patch in EPICS implements item 1 as it avoided any race condition accessing `ntpd` data. The implementation is heavy because it needs a UDP socket, sending and receiving of UDP packets and C string handling parse the data. It is a lot of code, memory and complexity to get data from one piece of memory to another. The `ntpq` approach is valid when `ntpd` is a separate process however I wonder if we can move to a simpler direct access method. The issue is the locking of the global `ntpd` peer list. The RTEMS port of `ntpd` has a lock to protect some global data. If `ntpd` held the lock when not blocked it would let calls request the lock and then direct access to the data. -- View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-net-services/-/issues/16 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
