On Tue, Dec 20, 2016 at 2:53 PM, Gedare Bloom <ged...@rtems.org> wrote:
> Option #1 writing a script is better. We occasionally add > implementations for POSIX features as needed for various compliance > test requirements or application portability. > > POSIX compliance is desirable within the limits of a single process environment. However, I see four basic categories of missing methods: + unimplementable - fork() for example. Disclaimer: I see this as implementable in some environments in which RTEMS is paravirtualized. + implementable but should be in newlib - missing math methods, etc. + implementable but should be in RTEMS - + don't care - there are some POSIX 2013 methods that I don't think anyone really wants. Much of what is missing at this point per the FACE POSIX profiles is things that need to be added to newlib. I don't have the list handy but can get Jeff to email it to you. The FACE Techncial Standard is at www.opengroup.org/face. You want Appendix A of version 2.1. FACE defines four POSIX profiles for avionics. RTEMS is close to meeting Safety Base. Gedare and I have pending commits for that. If you ignore the process related methods in Safety Extended, we will meet that also. General Purpose has ~800 of the ~1300 in POSIX 1003-2013. RTEMS has say 85% of those and many missing belong in newlib. I don't know how RTEMS does past General Purpose. What methods are you concerned about? --joel > On Thu, Dec 15, 2016 at 9:29 AM, Saeed Ehteshamifar > <salpha.2...@gmail.com> wrote: > > Hello, > > > > For Slingshot, an RTEMS-targeted fault-injection tool for the POSIX API, > I > > need to remove the tests that correspond to unimplemented/unimplementable > > POSIX functions/constants/etc. I can either > > 1. write a script that searches for "Unimplemented" and > "Unimplementable" in > > the doc's source, and removes the corresponding function's test cases > every > > time after generating test cases or, > > 2. manually delete all unimplemented/unimplementable from the Slingshot > core > > so that they aren't generated at all. > > > > Now the question is: Apart from unimplementable functions, is there any > > direction to implement unimplemented parts beyond the current situation? > > Cause in that case, I think writing a script is a better option. > > > > Best Regards, > > Saeed > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
