NTP client recommendation for RTEMS?

[Chris Johns]

On 21/3/2022 5:59 pm, Sebastian Huber wrote:
> On 20/03/2022 23:08, Chris Johns wrote:
>> On 24/2/2022 2:03 am, Sebastian Huber wrote:
>>> On 22/02/2022 21:25, Joel Sherrill wrote:
>>>> On Tue, Feb 22, 2022, 1:45 PM Sebastian Huber
>>>> <sebastian.huber at embedded-brains.de
>>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>>>
>>>>      On 22/02/2022 20:30, Joel Sherrill wrote:
>>>>       > On Tue, Feb 22, 2022 at 1:21 PM Sebastian Huber
>>>>       > <sebastian.huber at embedded-brains.de
>>>>      <mailto:sebastian.huber at embedded-brains.de>>  wrote:
>>>>       >> On 22/02/2022 19:22, Joel Sherrill wrote:
>>>>       >>> Are you planning to get the NTP server side of the freebsd-org
>>>>      code working?
>>>>       >>>
>>>>       >>> Or get it building but not testing it?
>>>>       >>>
>>>>       >>> Or just focusing on building and testing JUST the client part.
>>>>       >> I ported the ntpd from FreeBSD to an older version of the
>>>>      libbsd. I only
>>>>       >> tested the client part and this seems to work fine after some
>>>>      basic tests.
>>>>       > OK. That matches what I expected. Is the libbsd version to old to
>>>>      merge
>>>>       > against? Any plans to merge this?
>>>>       >
>>>>       > Alternatively, is your work available to be used as the basis for
>>>>      updating
>>>>       > to 6-freebsd-12?
>>>>
>>>>      I have a very long TODO list. Actually, I started with the current
>>>>      6-freebsd-12 branch, but it didn't work, so in principle generating
>>>>      patches for this branch should be easy.
>>>>
>>>> Thanks. If we end up working on this, we will sync with you to help and avoid
>>>> duplicate work.
>>>
>>> I pushed the NTP work to my github repository:
>>>
>>> https://github.com/sebhub/rtems-libbsd/tree/6-freebsd-12-ntpd
>>>
>>> I think we have to revert some changes done for the NFS support.
>>
>> Please do not. I would prefer the problem be discussed and understood first and
>> alternatives considered.
> 
> Yes, I don't work this currently.
> 
>>
>>> For example, I don't know why the system call support for kqueue and the
>>> sockets> moved to a separate file and was changed to use the FreeBSD file
>>> descriptors.
>>
>> The change lets us use FreeBSD fd support and after this work I think the change
>> is major improvement over the implementation I had to work with. Using RTEMS
>> direct fd support in mixed ways with VFS in LibBSD would only make things
>> confusing.
> 
> Using the FreeBSD file descriptors for the FreeBSD file system support makes
> sense. I don't understand why this is required for the kqueue and sockets
> support. It just adds a runtime, memory, and code overhead. You need this RTEMS
> file descriptor to FreeBSD file descriptor mapping in every send() and recv()
> call. Not everyone is using libbsd with the NFS client. What is the hard reason
> for having the FreeBSD file descriptors for kqueue and socket?

The code is in libbsd and part of the whole kernel framework we import and the
changes I made bring it closer to the original FreeBSD sources. This is still a
primary and overriding requirement for libbsd.

The changes cover:

1. Moving all the system calls into a single location [1] from a number of
places. In FreeBSD this code is in the user land libraries and so there is a
clear and defined boundary.

2. Localised trace support. This makes working with the system calls and porting
code to RTEMS and libbsd easier as you can see the system calls.

3. Uniform interfacing and management of IOP. We now have a better abstraction
which lets us change IOP or libio without a major impact on this code. This
includes the various dispatch tables RTEMS's file system requires.

4. FreeBSD fd and file management and locking. This is important.

The primary goal was to rebase the code to make it easier and simpler to work
with. I found a number of questionable subtle things hidden in the
implementation that conflicted with our goals for this code. I did not want
separate domains of file descriptors in libbsd based on file systems, networking
or something else.

The next step is to get these changes as implemented onto master. I am not sure
how I will manage to do this but I have to. After that if you feel there are
changes that can be made to improve performance, memory usage, etc then we can
consider each of them on their merit. At least then we will have a clearer trail
and understanding for the change.

Chris

[1]
https://github.com/RTEMS/rtems-libbsd/blob/6-freebsd-12/rtemsbsd/rtems/rtems-bsd-syscall-api.c