POSIX compliance development

[Joel Sherrill]

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.

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?

--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/20161221/8e8044a6/attachment-0002.html>