On Thu, Mar 21, 2019 at 9:05 AM Vaibhav Gupta <vaibhavgupt...@gmail.com> wrote:
> > > On Thu, Mar 21, 2019 at 6:10 PM Joel Sherrill <j...@rtems.org> wrote: > >> >> >> On Thu, Mar 21, 2019, 2:43 AM Vaibhav Gupta <vaibhavgupt...@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 >>> >>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
