<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;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><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><br></div><div>The FACE Techncial Standard is at <a href="http://www.opengroup.org/face">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><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Dec 15, 2016 at 9:29 AM, Saeed Ehteshamifar<br>
<div><div class="h5"><<a href="mailto:salpha.2004@gmail.com">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">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div>