<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">I have a few questions which I would like to resolve before sending in the patch.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Will the definitions for the wrapper functions go under cpukit/libtest like it</div><div class="gmail_default" style="font-size:small">is currently done for printf, puts, etc.? And also why are we wrapping printf</div><div class="gmail_default" style="font-size:small">and puts? Is it to provide definitions for BSPs that don't compile with POSIX</div><div class="gmail_default" style="font-size:small">and don't link against newlib?</div><div class="gmail_default" style="font-size:small"><div class="gmail_default"><div dir="ltr"><div class="gmail_default"><div class="gmail_default"><div class="gmail_default"><br></div><div class="gmail_default">2) How are we going to let the tests register a device tree? If we are placing the</div><div class="gmail_default">wrapper function under cpukit/libtest, one way would be to have an extern variable</div><div class="gmail_default">in that file which we initialize in the test executable. If we are placing it local</div><div class="gmail_default">to the test then we can define it in the test itself.</div><div class="gmail_default"><br></div></div><div class="gmail_default">3) I played around with the linker wrap options. And I want to make sure that I</div><div class="gmail_default">understand it correctly. In this patch, will we be using it in the following way?</div><div class="gmail_default"><br></div><div class="gmail_default">In openfirm.c we will have the following</div><div class="gmail_default">const void *bsp_fdt_get();</div><div class="gmail_default">void ofw_init() {</div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div class="gmail_default"><div class="gmail_default">...</div></div></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div dir="ltr"><div class="gmail_default"><div class="gmail_default">fdtp = bsp_fdt_get();</div></div></div></blockquote><div class="gmail_default">}</div><div class="gmail_default">In normal use case(when not testing)</div><div class="gmail_default">bsp_fdt_get will resolve to the original bsp_fdt_get function right?<br></div><div class="gmail_default"><br></div><div class="gmail_default">And while testing</div><div class="gmail_default"><div class="gmail_default">we will be linking the __wrap_bsp_get_fdt function with the test executable right?</div></div><div class="gmail_default">and all calls to bsp_get_fdt will resolve to __wrap_bsp_get_fdt</div><div dir="ltr"><div class="gmail_default"><div class="gmail_default"></div></div></div></div><div class="gmail_default"><br></div><div class="gmail_default">4) Are there any major changes that have to be made other than moving the</div><div class="gmail_default">files to cpukit?</div><div class="gmail_default"></div></div></div><div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default"><br></div></div><div class="gmail_default" style="font-size:small">5) Christian suggested that I define commonly used functions like malloc, free,</div><div class="gmail_default" style="font-size:small">KASSERT into a single header file which will be imported in every source file.</div><div class="gmail_default" style="font-size:small">This is to decrease the number of redefinitions for these functions.</div><div class="gmail_default" style="font-size:small">malloc has been defined as</div><div class="gmail_default" style="font-size:small">#define malloc(size, type, flag) malloc(size)</div></div><div class="gmail_default" style="font-size:small">We ignore the type and flags. Is that OK? The malloc implementation in RTEMS</div><div class="gmail_default" style="font-size:small">doesn't support types and flags will this cause any problem?</div><div class="gmail_default" style="font-size:small">There is a FreeBSD malloc implementation(rtems_bsdnet_malloc) under libnetworking</div><div class="gmail_default" style="font-size:small">can we move it to a commonplace so that other files can use it?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 4, 2020 at 11:38 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/06/2020 07:57, Chris Johns wrote:<br>
<br>
> On 4/6/20 3:22 pm, Sebastian Huber wrote:<br>
>> This approach avoids the need to actively register a device tree. This could<br>
>> simplify the low level startup a bit. The draw back is that it needs a special<br>
>> feature of the linker for the tests.<br>
> But we already use this feature and need it for the tests to link so does it<br>
> matter if it is used here?<br>
<br>
I am in favour of this approach using the linker wrap.<br>
<br>
</blockquote></div></div>