POSIX Compilance- #2966, GSoC Project 2019

Joel Sherrill joel at rtems.org
Mon Mar 18 15:14:35 UTC 2019


On Mon, Mar 18, 2019 at 8:49 AM 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/
>

This is for Cygwin -- not RTEMS. It is likely an implementation that would
work
for all x86 and x86_64 targets though. It should be moved to a more shared
location
in the source tree.

The implementations under libc/machine are specific to processor
architectures.
In this case SPU (the Cell processor from the Playstation as I recall) and
the RISC-V.

RTEMS needs implementations for ARM, PowerPC, SPARC, x86, and MIPS as a
good goal.

I know this is confusing but newilb and RTEMS have code that is shared
across
all configurations and code that is specific to a small subset.


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


More information about the devel mailing list