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