On Wed, Mar 25, 2020 at 4:40 PM Eshan Dhawan <eshandhawa...@gmail.com> wrote:
> > > 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. > > it is present in RTEMS libbsd but the compliance docs show that the function is still not implemented https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html#sys-select-h > >> >>> >>> > >>> > -> 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
