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
