POSIX Compilance- #2966, GSoC Project 2019
Vaibhav Gupta
vaibhavgupta40 at gmail.com
Tue Mar 19 15:46:25 UTC 2019
On Tue, Mar 19, 2019 at 12:39 AM Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Mon, Mar 18, 2019 at 12:01 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
> wrote:
>
>> 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
>>
>> Yep. Same guidelines as fenv.h except for a warning that some
> architectures
> do not have long double support so double is long double.
>
> I thought this had a ticket but apparently it is listed as one needing a
> ticket filed.
> Yes this one is higher priority than the lack of a ticket indicates. It
> needs a ticket
> filed. If it has the right keywords, it will show up in the master POSIX
> Compliance
> ticket.
>
I had a talk with Aditya and he mentioned that most of the work for long
complex is already done by him, so not much work is left.
>
> Good news, these appear to be included in FreeBSD now in the same directory
> I pointed you to for the fenv.h. So once you get the hang of adding things
> to
> newlib, this should be a very successful project.
>
> Experience says these tasks can be easy, hard, or need to be abandoned
> since
> the method won't work in a single process system like RTEMS so pick at
> least 5
> to attempt. fenv.h and the long double are a good start.
>
> What's left against FACE 3.0 General Purpose Profile?
>
> NOTE: There is an approved change request against FACE 3.0 to make '
> support for multiple processes optional. Any method listed in the FACE
> Technical Standard Edition 3.0, in Appendix A.1 as POSIX_MULTI_PROCESS
> is now optional.
>
>
> https://ticketing.facesoftware.org/face_user_bug_view.php?id=330&tab=submitter
>
> So FACE CR330 eliminated the requirement to support methods which RTEMS
> cannot support. With attention to the remaining APIs that are missing,
> RTEMS
> can meet FACE General Purpose.
>
> Sorry for the side discussion of that FACE CR. But it was filed so
> operating
> systems like RTEMS could meet the General Purpose Profile.
>
> I hope that made sense.
>
It did, Let me summarize what all things are left on FACE GPP
-- fenv.h
-- math functions:
- fpclassify()
- isfinite()
- isgreater()
- isgreaterequal()
- isless()
- islessequal()
- islessgreater()
- isnormal()
- isunordered()
- nexttowardf()
- signbit()
-- spawn function:
- posix_spawn()
- posix_spawn_file_actions_addclose()
- posix_spawn_file_actions_adddup2()
- posix_spawn_file_actions_addopen()
- posix_spawn_file_actions_destroy()
- posix_spawn_file_actions_init()
- posix_spawnattr_destroy()
- posix_spawnattr_getflags()
- posix_spawnattr_getpgroup()
- posix_spawnattr_getschedparam()
- posix_spawnattr_getschedpolicy()
- posix_spawnattr_getsigdefault()
- posix_spawnattr_getsigmask()
- posix_spawnattr_init()
- posix_spawnattr_setflags()
- posix_spawnattr_setpgroup()
- posix_spawnattr_setschedparam()
- posix_spawnattr_setschedpolicy()
- posix_spawnattr_setsigdefault()
- posix_spawnattr_setsigmask()
- posix_spawnp()
-- pselect() from <sys/select.h>
-- sockatmark() from <sys/socket.h>
-- confstr() from <unistd.h>
These Functions are not supported from FACE GPP.
And I guess they make a good project for GSoC
Moreover, Aditya gave me an init.c file, and I am trying to run it inside
testsuites,
as he said, it will give me more brief Idea for SoC Projects.
Thanks
Vaibhav Gupta
>
> --joel
>
>
>
>
>> .
>> 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/20190319/93e5decd/attachment-0002.html>
More information about the devel
mailing list