NTP client recommendation for RTEMS?

[Sebastian Huber]

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?

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