POSIX Compilance- #2966, GSoC Project 2019

Joel Sherrill joel at rtems.org
Mon Mar 18 19:09:09 UTC 2019


On Mon, Mar 18, 2019 at 12:01 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
wrote:

> Under "Tasks without Tickets":
> https://devel.rtems.org/ticket/2966#TasksWithoutTickets
> .
> .
>
> Newlib also has some known issues:
>
>    - math.h missing some methods
>       - long double complex methods. These could come from FreeBSD but we
>       need to be careful since there may be architecture specific
>       implementations. https://wiki.freebsd.org/Numerics
>
> Yep. Same guidelines as fenv.h except for a warning that some architectures
do not have long double support so double is long double.

I thought this had a ticket but apparently it is listed as one needing a
ticket filed.
Yes this one is higher priority than the lack of a ticket indicates. It
needs a ticket
filed. If it has the right keywords, it will show up in the master POSIX
Compliance
ticket.

Good news, these appear to be included in FreeBSD now in the same directory
I pointed you to for the fenv.h. So once you get the hang of adding things
to
newlib, this should be a very successful project.

Experience says these tasks can be easy, hard, or need to be abandoned since
the method won't work in a single process system like RTEMS so pick at
least 5
to attempt. fenv.h and the long double are a good start.

What's left against FACE 3.0 General Purpose Profile?

NOTE: There is an approved change request against FACE 3.0 to make '
support for multiple processes optional. Any method listed in the FACE
Technical Standard Edition 3.0, in Appendix A.1 as POSIX_MULTI_PROCESS
is now optional.

https://ticketing.facesoftware.org/face_user_bug_view.php?id=330&tab=submitter

So FACE CR330 eliminated the requirement to support methods which RTEMS
cannot support. With attention to the remaining APIs that are missing,
RTEMS
can meet FACE General Purpose.

Sorry for the side discussion of that FACE CR. But it was filed so
operating
systems like RTEMS could meet the General Purpose Profile.

I hope that made sense.

--joel




> .
> can we add missing methods for SoC for POSIX Compilance?
>
> On Mon, Mar 18, 2019 at 8:58 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
> wrote:
>
>>
>>
>> On Mon, Mar 18, 2019 at 8:51 PM Joel Sherrill <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Mon, Mar 18, 2019 at 9:06 AM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
>>> wrote:
>>>
>>>> Okay, i read the header file, the functions defined in
>>>>
>>>> https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#id396
>>>> are still missing.
>>>> .
>>>> Can they be taken up for SoC project?
>>>>
>>>
>>> Yep. As I tried to make clear on the other response, the implementation
>>> of fenv.h
>>> is target architecture dependent.
>>>
>>> + The Cygwin fenv.h is possibly x86 and/or x86_64. It can be moved as
>>> appropriate
>>> so the implementation is available to all users of that architecture.
>>>
>>> + Other architectures like ARM, PowerPC, SPARC, etc will need to be
>>> located
>>> and ported to newlib or written. Just a quick search of the net turned
>>> up this
>>> directory from FreeBSD's github which has a number of architectures.
>>>
>>> This by itself is not going to be a full GSoC project but it is a good
>>> first ticket to
>>> tackle in a set of POSIX Compliance tasks.
>>>
>> So, for now, I have got 1 ticket for POSIX Compilance for SoC.
>> As I went through documentation, following methods are also missing from
>> math.h
>>
>>    - fpclassify()
>>    - isfinite()
>>    - isgreater()
>>    - isgreaterequal()
>>    - isless()
>>    - islessequal()
>>    - islessgreater()
>>    - isnormal()
>>    - isunordered()
>>    - nexttowardf()
>>    - signbit()
>>
>> Can we add them up for GSoC?
>>
>> Thanks
>> Vaibhav Gupta
>>
>>>
>>> --joel
>>>
>>>
>>>> On Mon, Mar 18, 2019 at 7:19 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
>>>> wrote:
>>>>
>>>>> Ticket no #2971 https://devel.rtems.org/ticket/2971
>>>>>
>>>>> The header file is present in newlib:
>>>>>
>>>>> $ find ./ -name \fenv.h
>>>>> ./newlib-cygwin/winsup/cygwin/include/fenv.h
>>>>> ./newlib-cygwin/newlib/libc/machine/spu/sys/fenv.h
>>>>> ./newlib-cygwin/newlib/libc/machine/spu/include/fenv.h
>>>>> ./newlib-cygwin/newlib/libc/machine/riscv/sys/fenv.h
>>>>> ./newlib-cygwin/newlib/libc/machine/riscv/include/fenv.h
>>>>>
>>>>> ./newlib-cygwin/winsup/cygwin/include/fenv.h   contains full
>>>>> imlementation
>>>>> as defined on http://pubs.opengroup.org/onlinepubs/9699919799/
>>>>>
>>>>> On Mon, Mar 18, 2019 at 7:04 PM Vaibhav Gupta <
>>>>> vaibhavgupta40 at gmail.com> wrote:
>>>>>
>>>>>> Ticket no #3650 https://devel.rtems.org/ticket/3650
>>>>>>
>>>>>> The header file is present in newlib:
>>>>>> $ find ./ -name \ipc.h
>>>>>> ./newlib-cygwin/winsup/cygwin/include/sys/ipc.h
>>>>>> ./newlib-cygwin/winsup/cygwin/include/cygwin/ipc.h
>>>>>> ./newlib-cygwin/newlib/libc/sys/phoenix/sys/ipc.h
>>>>>> .
>>>>>> and
>>>>>> ./newlib-cygwin/winsup/cygwin/include/cygwin/ipc.h contains whole
>>>>>> implementation.
>>>>>> I guess, now we can enable the sys/ipc.h POSIX API Compliance Tests.
>>>>>>
>>>>>> On Sun, Mar 17, 2019 at 11:03 PM Vaibhav Gupta <
>>>>>> vaibhavgupta40 at gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Mar 17, 2019 at 9:43 PM Joel Sherrill <joel at rtems.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Mar 16, 2019, 2:49 PM Vaibhav Gupta <
>>>>>>>> vaibhavgupta40 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> As mentioned by Dr Joel that high priority is to be given to
>>>>>>>>> implementations missing in FACE GPP 3.0.
>>>>>>>>> So, I have got FACE Technical Standard 3.0 pdf downloaded. And its
>>>>>>>>> pretty easy to compare tickets now.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The FACE Technical Standard is a long and sleep inducing read. :)
>>>>>>>>
>>>>>>>> We have a POSIX Compliance document which tracks RTEMS vs various
>>>>>>>> POSIX profiles. Many standards have POSIX profiles. SCA is for software
>>>>>>>> radios. FACE TS was designed for cockpit software. Use the compliance
>>>>>>>> document for ease:
>>>>>>>>
>>>>>>>> https://docs.rtems.org/branches/master/posix-compliance/index.html
>>>>>>>>
>>>>>>> Thanks, I guess this document contains the list of methods that are
>>>>>>> already supported. I was comparing tickets with FACE to find which all are
>>>>>>> still in need to be addressed.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> I track compliance against every standard I can find.
>>>>>>>>
>>>>>>> This is best for RTEMS
>>>>>>>
>>>>>>>>
>>>>>>>> FYI I have supported the FACE Consortium for a number of years in
>>>>>>>> various roles.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> .
>>>>>>>>> And while exploring big picture I got many questions:
>>>>>>>>>
>>>>>>>>> 1 - It is mentioned in the ticket #2966, *"RTEMS POSIX Compliance
>>>>>>>>> is achieved via a combination of methods and .h files in RTEMS and the
>>>>>>>>> newlib C Library."* .
>>>>>>>>> So, if a method or a header is present in Newlib C, it is not
>>>>>>>>> required to be present in RTEMS library? But that would mean Newlib is
>>>>>>>>> directly ported to RTEMS.
>>>>>>>>>
>>>>>>>>
>>>>>>>> POSIX includes the entire C Library in its definition. Newlib is
>>>>>>>> our C Library so if the method makes sense to be there, we add it to
>>>>>>>> Newlib.
>>>>>>>>
>>>>>>>> In general, threading and synchronisation go in RTEMS. But ask for
>>>>>>>> specific methods. It isn't always obvious.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>> *> I had an off-list talk with Vijay, he proved to be very
>>>>>>>>> helpful. I asked him same question (question 1), I would like to conclude
>>>>>>>>> what we discussed. *
>>>>>>>>>
>>>>>>>>> *> He told that "RTEMS uses its own version of Newlib C as it
>>>>>>>>> cannot directly mirror original Newlib as, if methods change the way it
>>>>>>>>> works, they can break RTEMS".*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *> But then my doubt was, if that's the case, why keep modified
>>>>>>>>> headers of original Newlib under separate Newlib C folder in RTEMS? Why not
>>>>>>>>> directly include them in RTEMS library? (As I found newlib-1d35a003f.tar.gz
>>>>>>>>> in {RTEMS-ROOT}/rsb/rtems/sources/    )*
>>>>>>>>> *.*
>>>>>>>>> *> To which he replied,  "RTEMS version of newlib is being used as
>>>>>>>>> a libraby of RTEMS only and the posix functions are being linked to this
>>>>>>>>> newlib"*
>>>>>>>>> .
>>>>>>>>> 2- So, My second doubt is that our target is to contribute to
>>>>>>>>> Newlib C or RTEMS Library? Or we will add methods to Newlib C and link them
>>>>>>>>> to RTEMS?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Vaibhav Gupta
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190318/18cf6507/attachment-0002.html>


More information about the devel mailing list