Google Summer of Code | New APIs Added to POSIX Standard (Issue 8) (#69)

Joel Sherrill (@joel) gitlab at rtems.org
Fri Apr 25 21:14:13 UTC 2025




Joel Sherrill commented: https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/69#note_122270


@mez3n Odd comments and hopefully Gitlab will allow us to fold the tables into one back in the issue description.

If the implementation is already in newlib, make sure there is an API header OK test in psxtests/psxhdrs and plan to add a functionality test to RTEMS (likely in psxtests).

If an API needs adding to a header in newlib, then we need to put that near the front of the todo list. Once a patch to add the prototype a newlib header is posted to newlib's mailing list, it will have to go through their review cycle and get merged (I can do that once someone says OK). Once merged, we will want to update the newlib hash in the RTEMS tools in the RSB. Tedious and likely easier all around to get all header file updates in early and then avoid toolset churn. Looks like I did us a favor by adding new functions to pthread.h a while back.

Yes. dladdr() needs to get added to the dlfcn.h you found.

For timespec_get(), we need to get the prototype in newlib and I think the implementation can go there also.

For POSIX/BSD network headers, the master set used by RTEMS is in newlib. Those can be used with the legacy stack, lwip, or libbsd. They may define things not supported by a particular network stack. ppoll() would only be implemented in libbsd. It may be more reliable to build libbsd and check the library to see if ppoll() is in it.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/69#note_122270
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250425/191df7a0/attachment.htm>


More information about the bugs mailing list