POSIX compliance development

[Saeed Ehteshamifar]

On Thu, Dec 22, 2016 at 12:28 AM, Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Tue, Dec 20, 2016 at 2:53 PM, Gedare Bloom <gedare at 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.2004 at 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 at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20161226/99d4bc61/attachment-0002.html>