Sub-Tickets selected for POSIX Compilance GSoc Project

[Joel Sherrill]

On Thu, Mar 21, 2019 at 9:05 AM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
wrote:

>
>
> 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.
>

+1  Add them to rtems-libbsd


>
>>>
>>>    - -- 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.
>

Good catch. The FACE ticket for allowing multiple processes to be optional
missed _POSIX_SPAWN. Luckily it hasn't made a release and I was just
addressing
this earlier this week. So I need to correct the FACE ticket. :)

>
>> 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/483fefc0/attachment.html>