<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 23 Mar 2020 at 06:47, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</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 Sun, Mar 22, 2020 at 8:46 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Sun, Mar 22, 2020, 1:58 AM Vaibhav Gupta <<a href="mailto:vaibhav.varodek@gmail.com" target="_blank">vaibhav.varodek@gmail.com</a>> wrote:<br>
>>><br>
>>><br>
>>> > My very quick review shows that this may all be present and then it is a matter<br>
>>> > of test cases and the compliance document. And that's a good result. Sometimes<br>
>>> > people do work and don't update tickets.<br>
>>> ><br>
>>> My hazy recollection is that someone looked into this. Maybe in prior<br>
>>> POSIX Compliance projects?<br>
>><br>
>><br>
>> Last year when I was porting ndbm.h I made several queries regarding this directory.<br>
>> Even after doing all the changes correctly, the port was not successful. Later I found<br>
>> out that the ndbm was calling a hash function from search.h.<br>
>><br>
>> The headers in this directory need to be updated first. Me and Joel even had<br>
>> discussion about this in newlib mailing list but got no positive response from them.<br>
>><br>
>> <a href="https://sourceware.org/pipermail/newlib/2019/017046.html" rel="noreferrer" target="_blank">https://sourceware.org/pipermail/newlib/2019/017046.html</a><br>
>><br>
>> <a href="https://lists.rtems.org/pipermail/devel/2019-June/026205.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2019-June/026205.html</a><br>
><br>
><br>
> The newlib link doesn't work after the sourceware upgrade :(<br>
><br>
> Let's assume this code needs to be updated to the latest freebsd and then freebsd ndbm brought over.<br>
<br>
Vaibhav, can you help Eshan to understand what you discovered last<br>
year, and work on a plan for this summer to address this challenge?<br></blockquote><div>Sure,</div><div><br></div><div>1) Eshan, I would strongly suggest you to go through my threads in rtems mailing</div><div>list as well as newlib mailing list, of last year.</div><div><br></div><div>2) Keep the task of updating search.h, secondary because last year newlib</div><div>community didn't show much interest in this. Hence while porting ndbm,</div><div>I changed the ndbm code from BSD, rather than updating search.</div><div><br></div><div><div>3) I saw you query regarding ftw.h also.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div>Go through my logs of weekly meetings: <a href="https://devel.rtems.org/wiki/GSoC/2019#VaibhavGupta">https://devel.rtems.org/wiki/GSoC/2019#VaibhavGupta</a> .</div><div>Last year w<span style="color:rgb(0,0,0);font-family:Verdana,Arial,"Bitstream Vera Sans",Helvetica,sans-serif;font-size:13px">hile porting ftw, I saw it requires fts.h, the functions of fts.h are defined in fts.c which</span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,"Bitstream Vera Sans",Helvetica,sans-serif;font-size:13px">requires mount.h, again this header requires multiple other headers, and dependency chain is formed.</span></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,"Bitstream Vera Sans",Helvetica,sans-serif;font-size:13px">So, in simple words, porting one header was leading to porting of 10-20 other headers.</span></div><div><font color="#000000" face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif"><span style="font-size:13px">So when you try to port ftw, first discover all the dependencies and plan it.</span></font></div><div><font color="#000000" face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif"><span style="font-size:13px"><br></span></font></div><div><font color="#000000" face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif"><span style="font-size:13px">4) Last year Joel mentioned that compliance to FACE GPP is of atmost priority,</span></font></div><div><font color="#000000" face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif"><span style="font-size:13px">so start working with them you will find the missing functions here:</span></font></div><div><a href="https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#face-3-0-general-purpose">https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#face-3-0-general-purpose</a></div><div><br></div><div>5) fenv.h is also at same priority level. Joel made things very easy.</div><div>He made a dummy model of fenv port at newlib-cygwin/newlib/libm/fenv</div><div>He defined how fenv should be ported for other architectures. </div><div>Just go through those non-functional codes, and you will get idea</div><div>how to port fenv for a specific architecture and the location of their port.</div><div><br></div><div>6) For writing testsuites, I used to write them for linux first, since both rtems and linux</div><div>follow POSIX. So I could easily run in on my system  like any regular C program</div><div>and debug it for syntactical, semantic and logical error. then port it to RTEMS and look</div><div>for run-time errors.</div><div><br></div><div>-- Vaibhav Gupta</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>><br>
>><br>
>> --Vaibhav Gupta<br>
</blockquote></div></div>