On Wed, Mar 25, 2020 at 4:18 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Tue, Mar 24, 2020 at 5:33 PM Gedare Bloom <ged...@rtems.org> wrote: > >> email subject can be shortened. almost everything is a discussion :) >> >> On Tue, Mar 24, 2020 at 3:49 PM Eshan Dhawan <eshandhawa...@gmail.com> >> wrote: >> > >> > Hello everyone, >> > I have identified sources to port headers and methods to RTEMS and >> Newlib. I have given priority to FreeBSD for the choice of source. But >> method not present in FreeBSD can be ported from alternative sources like >> NetBSD and musl. >> > >> Considering the simplicity, you may want to compare musl vs freebsd as >> well. >> >> > -> Missing methods of math.h: I have compiled a list of methods and >> their sources. Some need to be implemented from scratch. >> > list: Math.h missing functions >> > >> > -> sys/ipc.h: This header and its function can be ported from FreeBSD. >> > ipc.h : https://github.com/freebsd/freebsd/blob/master/sys/sys/ipc.h >> > ftok.c: >> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/ftok.c > > > sys/ipc.h has a lot in it. If you head down the path of adding sys/ipc.h, > you need to evaluate what else is in the file. > > Adding support for the System V style SHM, Semaphores, or Message Queues > is possible (I think) but is definitely harder than the likely value to the > community. > I would like to know missing headers and methods that would be more valuable to the community > >> > >> > ->fmtmsg.h: its implementation is also present in FreeBSD. >> > https://github.com/freebsd/freebsd/blob/master/include/fmtmsg.h >> > https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/fmtmsg.c > > > By my recollection, this would be a discrete thing to add to Newlib. > >> >> > >> > ->spawn.h: Its implementation is in FreeBSD. >> > >> https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/posix_spawn.c >> > >> I'm worried about the large number of includes there. It may easily >> lead you to trouble chasing down transitive include headers, like what >> happened with Vaibhav before with search.h support. >> > > posix_spawn() cannot be supported by RTEMS. It is a new safer way to do > fork/exec. Don't spent any time on this. It will never work on RTEMS. > > It is also a HUGE amount of methods and constants. :( > Ok I will remove it from the proposal > >> > -> pselect() from <sys/select.h> : its implementation is also from >> FreeBSD >> > https://github.com/freebsd/freebsd/blob/master/lib/libc/sys/pselect.c > > > This would be added to rtems-libbsd. There may be specific technical > challenges > why it is not present. Or it could just be an oversight. > I haven't dig that deep. > > >> >> > >> > -> confstr() from <unistd.h>: Its implementation is from FreeBSD >> > https://github.com/udp/freebsd-libc/blob/master/gen/confstr.c. >> > > The implementation of this would go in RTEMS. > > It is possible that the FreeBSD code is a guide but this cannot be a direct > copy to port. Each value defined by POSIX as fetchable must be properly > defined for RTEMS. You would need to make a table of all the "names" > that can be looked up in your proposal. > what would be better writing it from scratch of just doing minor tweaks in the FreeBSD code We also have an option to take code from musl https://git.musl-libc.org/cgit/musl/tree/src/conf/confstr.c > > FWIW I think the FreeBSD version is more right than wrong for RTEMS > but it can't be 100% right and needs analysis. > > > >> > I would like everyone to review it and provide your suggestions. >> > >> include details in your proposal also. >> > > +1 > I have already added these detatils to the proposal > but will change spawn.h > >> >> > Thanks >> > -Eshan >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
