On Thu, Dec 22, 2016 at 12:28 AM, Joel Sherrill <j...@rtems.org> wrote:
> > > 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. > If it's "rtems_face.csv", you've sent it to me last year. It's a 1124-lines long file that begins like: "IEEE Std 1003.1-2008 API,RTEMS,Security,Safety Base,Safety Extended,General Purpose,POSIX Functionality Categories posix_fadvise,no,,,,,_POSIX_ADVISORY_INFO" > > 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? > 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. 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? > > --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