POSIX compliance development

[Joel Sherrill]

On Dec 26, 2016 1:28 PM, "Saeed Ehteshamifar" <salpha.2004 at gmail.com> wrote:



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.


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.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/f8be3c94/attachment-0002.html>