discussion related to source for porting headers and methods to RTEMS and newlib
Eshan Dhawan
eshandhawan51 at gmail.com
Wed Mar 25 18:36:26 UTC 2020
On Wed, Mar 25, 2020 at 4:40 PM Eshan Dhawan <eshandhawan51 at gmail.com>
wrote:
>
>
> On Wed, Mar 25, 2020 at 4:18 AM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Tue, Mar 24, 2020 at 5:33 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> email subject can be shortened. almost everything is a discussion :)
>>>
>>> On Tue, Mar 24, 2020 at 3:49 PM Eshan Dhawan <eshandhawan51 at 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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200326/520dd368/attachment-0001.html>
More information about the devel
mailing list