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.hu...@embedded-brains.de <mailto:sebastian.hu...@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.

_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to