> Do you have a list of the methods? > Yes. https://drive.google.com/file/d/0BzwRg-R9g_6tY3dfYjBfQUppMzhIRnpXRWNzU0JQa1ZlUHZV/view?usp=sharing and https://drive.google.com/file/d/0BzwRg-R9g_6tRG56OFk0SmxLS3pucVRKTjd6ckpXNm1kUmFJ/view?usp=sharing I was surprised hearing POSIX 1003-2013 has ~1300 functions! These lists are ~350-lines long.
> > > 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. > Right. > > Is there a middle ground of disabling them? > I think the middle ground is writing the script as I proposed. One extreme is to completely remove unsupported functions (even those that might be supported in the future!) from the functions list. The other extreme is to let all in, encounter a "not-defined" compile error, and resolve it by removing the corresponding test case (difficult). > > >> --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