POSIX Compilance- #2966, GSoC Project 2019

Mon Mar 18 17:00:24 UTC 2019

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

.
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/094f2e33/attachment-0001.html>