POSIX Compilance- #2966, GSoC Project 2019

[Vaibhav Gupta]

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/3bd4398b/attachment-0001.html>