POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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/8c1a32fe/attachment-0001.html>