POSIX Compilance- #2966, GSoC Project 2019

[Joel Sherrill]

On Mon, Mar 18, 2019 at 10:29 AM 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?
>

This appears to be the set defined in fenv.h so yes this is one of the
tasks under the
POSIX Compliance umbrella. Remember this one will involve providing
implementations
for multiple architectures and test code.

--joel

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