[libbsd 10/22] Update CONTRIBUTING.rst

[Sebastian Huber]

On 27/06/2022 06:40, Chris Johns wrote:
> Hi Sebastian,
> 
> Thank you for this submission. It will take a time for me to work through all
> the changes in detail and I may need your assistance if that is OK? I am heading
> out of town so I am sorry it will not be this week.
> 
> On 24/6/2022 4:33 pm, Sebastian Huber wrote:
>> +Porting Advice
>> +==============
>> +
>> +In FreeBSD there is a kernel and user space separation.  The kernel is invoked
>> +by applications through system calls.  These system calls are usually
>> +implemented by associated ``kern_*()`` functions.  For example, the
>> +``select()`` system call is implemented by ``kern_select()``.  In RTEMS, there
>> +is no kernel and user space separation.  The system call functions should be
>> +added directly after the associated ``kern_*()`` function.  The associated
>> +``kern_*()`` function should be made static.  This allows the compiler to
>> +remove the function call.  It may also reduce the need for stack variables in
>> +favour of registers for parameters.  Placing the system calls directly to the
>> +kernel implementation helps the linker to only include code needed by the
>> +application and works well with the linker set based LibBSD initialization.  It
>> +also helps during FreeBSD baseline updates since changes in the kernel
>> +implementation may be indicated through merge conflicts and this may highlight
>> +fixes in the porting code.
> 
> I will try and discuss this topic with Joel and Gedare this week. Our previous
> discussion on this topic concluded the key objective for LibBSD is source
> transparency and that means taking the source with as few changes as possible.
> We was this micro-optimisations. This is why the code was changed.

The key objective is being able to keep up to date with FreeBSD. Having 
__rtems__ blocks after functions is really not an issue during updates. 
 From experience, what is really annoying are white space changes 
introduced by smart editors.

I updated for example uipc_syscalls.c 15 times from FreeBSD 8.4 to 
stable/12 2019-09-23, so my reasoning is based on experience and not 
just theoretical discussions.

I had no time to do updates in the past two years, so no updates 
happened during this time. Some Xilinx drivers and the NFS code is not 
included in the master branch. When the master branch is updated (for 
example to get support for wireguard), it will get harder to add the 
support from 6-freebsd-12 to master. This is also something you could 
discuss.

> 
> It would be interesting to see what effect LTO has? It maybe a cleaner path forward.

LTO doesn't really help here. The system initialization items are marked 
as used and are excluded from the linker garbage collection. 
Centralizing the high level entry points into LibBSD in a single file 
was a really bad idea.

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