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. It would be interesting to see what effect LTO has? It maybe a cleaner path forward. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
