NTP client recommendation for RTEMS?

Tue Mar 22 06:46:46 UTC 2022

On 21/03/2022 22:28, Chris Johns wrote:
> 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.

Being close to the FreeBSD code is just one goal. I made a couple of 
updates in the past and the kqueue and socket modules didn't cause 
issues. The RTEMS-specific code were clearly isolated in well defined 
places.

> 
> 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.

Moving the system call glue to a separate file makes it more difficult 
to review. Previously, the glue code and the system call implementation 
was very close together in the code. There is a one-to-one relationship 
between the API function and the sys_*() or kern_*() implementation. 
Having the code in one module makes it possible to make the 
implementation static. This avoids a function call overhead and enables 
the compiler to optimize the parameter handover structure away. It 
avoids an extra stack frame.

> 
> 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.

The trace support could have been easily added to the existing kqueue 
and socket modules. Independent of this, why was there a specialize 
tracing support added? I thought the trace linker was the tool to trace 
applications?

> 
> 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.

This just adds another level of complexity for the kqueue and socket 
support. I am not talking here about the NFS file system code.

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

What do you mean in detail here with respect to the socket support. What 
is the hard reason to have the FreeBSD file descriptors in this area?

> 
> 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.

What do you mean with "a number of questionable subtle things hidden in 
the implementation"? Updating the kqueue and socket code from one 
FreeBSD baseline to another was not an issue so far. The problem areas 
are the UMA support and new synchronization primitives like the Epoch 
based reclamation.

> 
> 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.

I plan to revert the use of the FreeBSD file descriptors in kqueue and 
socket. This is just an extra layer of complexity and runtime overhead 
with no justified functional benefit as far as I see this currently.

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

-- 
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/