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. > >> >> - -- 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 >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
