Sub-Tickets selected for POSIX Compilance GSoc Project

[Vaibhav Gupta]

On Thu, Mar 21, 2019 at 6:10 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, Mar 21, 2019, 2:43 AM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
> wrote:
>
>> Hello,
>> After series of discussions and exploring things, I got Idea about
>> various things in this project.
>> I have got Interested in following sub-tickets:
>> -- #2970 - Add ftw.h to Newlib : https://devel.rtems.org/ticket/2970
>> -- #2971 - Add fenv.h to Newlib : https://devel.rtems.org/ticket/2971
>> -- #2972 - Add ndbm.h support : https://devel.rtems.org/ticket/2972
>> -- #3639 - Add fmtmsg.h to Newlib : https://devel.rtems.org/ticket/3639
>> -- #3650 - Add sys/ipc.h to Newlib : https://devel.rtems.org/ticket/3650
>>
>
> This should be low priority.
>
> -- #2973 - Enable getdate() in Newlib :
>> https://devel.rtems.org/ticket/2973
>> -- #2974 - Enable search.h functionality in Newlib :
>> https://devel.rtems.org/ticket/2974
>> -- Requrement from FACE GPP :
>>
>>    - -- math functions:
>>    - fpclassify()
>>       - isfinite()
>>       - isgreater()
>>       - isgreaterequal()
>>       - isless()
>>       - islessequal()
>>       - islessgreater()
>>       - isnormal()
>>       - isunordered()
>>       - nexttowardf()
>>       - signbit()
>>
>>
> This is fenv.h and IMO is higher priority for architectures where you are
> porting existing implementations.
>
Yah, so during my SoC time I will start with them first.
I guess I may find them on FreeBSD, had a little search on net.
Will get deeper in the topic once the sub-tasks are confirmed,
as for now I am going through tickets for POSIX Compliance.

>
>>
>>    - -- pselect() from <sys/select.h>
>>    - -- sockatmark() from <sys/socket.h>
>>
>> Sebastian.. are these not in the new tcpip stack?
>
> And agree with Sebastian on the *at methods.
>
That's great. I am ready to work on them.

>
>
>>    - -- confstr() from <unistd.h>
>>
>>
>>
>>    - -- 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(
>>
>> Spawn is a safer alternative to fork and exec. This requires
> multi-process support and thus these are not implementable on RTEMS.
>
Yah, i had this query in my mind, but then they were also not tagged as
POSIX_MULTI_PROCESS in FACE Technical Standards 3.0
and as you said about multi-process functions to be optional, i was not
able to conclude about them.
So I will leave it.

>
> If there is an existing ticket, it needs to state this.
>
>
>
>> If they all compile into a good GSoC project, I would like to start
>> writing a draft proposal.
>>
>> Thanks
>> Vaibhav Gupta
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190321/b01537d4/attachment-0002.html>