[PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Sebastian Huber]

On 04/06/2020 14:53, Niteesh G. S. wrote:

> I have a few questions which I would like to resolve before sending in 
> the patch.
>
> 1) Will the definitions for the wrapper functions go under 
> cpukit/libtest like it
> is currently done for printf, puts, etc.?
No, the wrapper function should be defined along with the test.
> And also why are we wrapping printf
> and puts? Is it to provide definitions for BSPs that don't compile 
> with POSIX
> and don't link against newlib?
This is a hack to work around issues with the use of the floating point 
unit in printf().
>
> 2) How are we going to let the tests register a device tree? If we are 
> placing the
> wrapper function under cpukit/libtest, one way would be to have an 
> extern variable
> in that file which we initialize in the test executable. If we are 
> placing it local
> to the test then we can define it in the test itself.
I would define the wrapper in the tests.
>
> 3) I played around with the linker wrap options. And I want to make 
> sure that I
> understand it correctly. In this patch, will we be using it in the 
> following way?
>
> In openfirm.c we will have the following
> const void *bsp_fdt_get();
> void ofw_init() {
>
>     ...
>
>     fdtp = bsp_fdt_get();
>
> }
> In normal use case(when not testing)
> bsp_fdt_get will resolve to the original bsp_fdt_get function right?
>
> And while testing
> we will be linking the __wrap_bsp_get_fdt function with the test 
> executable right?
> and all calls to bsp_get_fdt will resolve to __wrap_bsp_get_fdt
Yes, references to bsp_get_fdt will be resolved to __wrap_bsp_get_fdt 
and references to __real_bsp_get_fdt will be resolved to bsp_get_fdt by 
the linker.
>
> 4) Are there any major changes that have to be made other than moving the
> files to cpukit?
I haven't looked at the file content yet.
>
> 5) Christian suggested that I define commonly used functions like 
> malloc, free,
> KASSERT into a single header file which will be imported in every 
> source file.
> This is to decrease the number of redefinitions for these functions.
> malloc has been defined as
> #define malloc(size, type, flag) malloc(size)
> We ignore the type and flags. Is that OK? The malloc implementation in 
> RTEMS
> doesn't support types and flags will this cause any problem?

This is fine.

> There is a FreeBSD malloc implementation(rtems_bsdnet_malloc) under 
> libnetworking
> can we move it to a commonplace so that other files can use it?
No, please keep libnetworking as is. This is more or less read-only code.
>
> On Thu, Jun 4, 2020 at 11:38 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 04/06/2020 07:57, Chris Johns wrote:
>
>     > On 4/6/20 3:22 pm, Sebastian Huber wrote:
>     >> This approach avoids the need to actively register a device
>     tree. This could
>     >> simplify the low level startup a bit. The draw back is that it
>     needs a special
>     >> feature of the linker for the tests.
>     > But we already use this feature and need it for the tests to
>     link so does it
>     > matter if it is used here?
>
>     I am in favour of this approach using the linker wrap.
>