<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Dec 26, 2016 1:28 PM, "Saeed Ehteshamifar" <<a href="mailto:salpha.2004@gmail.com">salpha.2004@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div class="quoted-text">On Thu, Dec 22, 2016 at 12:28 AM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_-7279670688248873616gmail-">On Tue, Dec 20, 2016 at 2:53 PM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Option #1 writing a script is better. We occasionally add<br>
implementations for POSIX features as needed for various compliance<br>
test requirements or application portability.<br>
<br></blockquote><div><br></div></span><div>POSIX compliance is desirable within the limits of a single process environment.</div><div>However, I see four basic categories of missing methods:</div><div><br></div><div>+ unimplementable - fork() for example. </div><div>   Disclaimer: I see this as implementable in some environments in which</div><div>   RTEMS is paravirtualized.</div><div>+ implementable but should be in newlib - missing math methods, etc.</div><div>+ implementable but should be in RTEMS - </div><div>+ don't care - there are some POSIX 2013 methods that I don't think</div><div>   anyone really wants.</div><div><br></div><div>Much of what is missing at this point per the FACE POSIX profiles is</div><div>things that need to be added to newlib. I don't have the list handy but</div><div>can get Jeff to email it to you.</div></div></div></div></blockquote></div><div>If it's "rtems_face.csv", you've sent it to me last year. It's a 1124-lines long file that begins like:<br>"IEEE Std 1003.1-2008 API,RTEMS,Security,Safety Base,Safety Extended,General Purpose,POSIX Functionality Categories<br>posix_fadvise,no,,,,,_POSIX_<wbr>ADVISORY_INFO"<br><br></div><div class="quoted-text"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>The FACE Techncial Standard is at <a href="http://www.opengroup.org/face" target="_blank">www.opengroup.org/face</a>. You</div><div>want Appendix A of version 2.1. FACE defines four POSIX profiles</div><div>for avionics. RTEMS is close to meeting Safety Base. Gedare and I </div><div>have pending commits for that. If you ignore the process</div><div>related methods in Safety Extended, we will meet that also. General</div><div>Purpose has ~800 of the ~1300 in POSIX 1003-2013. RTEMS has</div><div>say 85% of those and many missing belong in newlib. I don't know</div><div>how RTEMS does past General Purpose.</div><div><br></div><div>What methods are you concerned about?</div></div></div></div></blockquote></div><div>Many methods that originally Ballista is concerned about plus possible methods added during original Slingshot project. I don't know if they lie in a specific profile or even if they cover POSIX 1003-2013 completely.<br></div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Do you have a list of the methods?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Are the list of unimplemented functions in docs + rtems_face.csv up to date? Can I depend solely on it to remove unsupported test cases? Or it's better to go through RTEMS source code to check if a certain function is implemented?<br></div><div class="elided-text"><div> </div></div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I think it is largely correct but some methods have been added and Gedare is about to commit some mmap methods.</div><div dir="auto"><br></div><div dir="auto">You can't solely go through RTEMS source code because many of the methods are provided by newlib. </div><div dir="auto"><br></div><div dir="auto">Also there are methods missing which should be in newlib eventually.</div><div dir="auto"><br></div><div dir="auto">Is there a middle ground of disabling them?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="elided-text"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_-7279670688248873616gmail-HOEnZb"><font color="#888888"><div><br></div><div>--joel</div></font></span><span class="m_-7279670688248873616gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Dec 15, 2016 at 9:29 AM, Saeed Ehteshamifar<br>
<div><div class="m_-7279670688248873616gmail-m_-31490284498327794h5"><<a href="mailto:salpha.2004@gmail.com" target="_blank">salpha.2004@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> For Slingshot, an RTEMS-targeted fault-injection tool for the POSIX API, I<br>
> need to remove the tests that correspond to unimplemented/unimplementable<br>
> POSIX functions/constants/etc. I can either<br>
> 1. write a script that searches for "Unimplemented" and "Unimplementable" in<br>
> the doc's source, and removes the corresponding function's test cases every<br>
> time after generating test cases or,<br>
> 2. manually delete all unimplemented/unimplementable from the Slingshot core<br>
> so that they aren't generated at all.<br>
><br>
> Now the question is: Apart from unimplementable functions, is there any<br>
> direction to implement unimplemented parts beyond the current situation?<br>
> Cause in that case, I think writing a script is a better option.<br>
><br>
> Best Regards,<br>
> Saeed<br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/devel</a><br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/devel</a><br>
</blockquote></span></div><br></div></div>
</blockquote></div></div><br></div></div>
</blockquote></div><br></div></div></div>