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

[Niteesh G. S.]

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.? 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?

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.

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

4) Are there any major changes that have to be made other than moving the
files to cpukit?

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

On Thu, Jun 4, 2020 at 11:38 AM Sebastian Huber <
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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200604/5901d18c/attachment.html>