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.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
