On Dec 26, 2016 1:28 PM, "Saeed Ehteshamifar" <salpha.2...@gmail.com> wrote:
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. Do you have a list of the methods? 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? I think it is largely correct but some methods have been added and Gedare is about to commit some mmap methods. You can't solely go through RTEMS source code because many of the methods are provided by newlib. Also there are methods missing which should be in newlib eventually. Is there a middle ground of disabling them? > --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
