posix: allow for external implementation of option groups

[cfriedt]

CONFIG_TC_PROVIDES_...

This provides external C libraries with a convenient mechanism for overriding Zephyr's POSIX API, at Option Group granularity.

Each implemented standard POSIX Subprofiing Option Group already has a Kconfig option in Zephyr. This Kconfig option is used to ensure that any appropriate feature test macros are defined (features.h), that any appropriate sysconf() values are returned, and of course to enable compilation of the relevant Zephyr C source files via CMake.

Generally, these existing Kconfig options have the form CONFIG_POSIX_xxxx, where POSIX_xxxx is the name of a standard IEEE 1003.1-2017 Option Group.

We add a number of Kconfig options in Kconfig.toolchain, all of the form CONFIG_TC_PROVIDES_POSIX_xxxx. Selecting these options instruct CMake to bypass the usual rules for compiling Zephyr's implementation of the selected POSIX Option Group.

The TC_PROVIDES Kconfig options are not user configurable, as they are intended to be used primarily by maintainers, and should be selected by a separate Kconfig option.

This is useful, for example, if a specific C library has a smaller, or faster, or more secure version of some POSIX features. Perhaps a vendor has a very specific implementation that is already certified on their device. There could be a number of reasons.

Why only Option Groups? Why not Options?

Subprofiling Option Groups such as POSIX_THREADS_BASE differ from POSIX Options like _POSIX_THREAD_ATTR_STACKADDR in that the Option Group is a mostly autonomous unit of functionality, while Options may just change one aspect of behaviour inside one or more a units of functionality.

The granularity was chosen to be at the Option Group level because implementations are most likely to be cleanly interoperable at Option Group level of abstraction, and because those are the lines officially drawn by IEEE to split up POSIX functionality.

Individual POSIX Options (e.g. _POSIX_THREAD_SAFE_FUNCTIONS) are often not as easily separated from other features that they may be tied to. Moreover, a given function may be required by more than one POSIX Option.

However, we may be able to add similar mechanisms for Options on a case-by-case basis in the future.

[keith-packard]

This looks like a really nice addition to the environment. Grouping them like this also seems entirely reasonable, and would encourage toolchains to provide complete implementations of an option group rather than cherry-picking individual functions.

[keith-packard]

Do we want to add the XSI option groups to this list? Afaict, that would be:

• CRYPT
• REALTIME
• ADVANCED_REALTIME
• REALTIME_THREADS
• ADVANCED_REALTIME_THREADS
• TRACING
• XSI_STREAMS
• ENH_I18N
• SHM

Digging through the POSIX specs to find stuff like this isn't easy; I couldn't find a comprehensive list of things beyond the subprofiling option groups.

Are there dependencies between option groups that we should be validating here? That would require a fairly deep reading of all of these option groups specifications, so I'd be fine with "no" or "maybe later" as answers.

[cfriedt]

Do we want to add the XSI option groups to fine with "no" or "maybe later" as answers.

Maybe later is probably safe. If anything, we can say it's a bug to not accurately represent XSI groups.

It's kind of surprising how many option groups there are too.

Also kind of surprising is that there will be another rev to the POSIX spec later this year! It's like the Energizer Bunny!

[cfriedt]

rebased

[nashif]

rebased

fix that complaince issue please

[aescolar]

Bulk changing the milestone from everything which did not make it to the v3.7.0 freeze deadline
and which is not labeled as a bug or documentation (or does not appear clearly as only containing
a bug fix or a documentation change).
If you disagree about this change please add the milestone again.

Please note that until rc2 only PRs containing bug fixes, docs and tests can be merged.
After that and until release only bug fixes and docs changes.

Exceptions require approval by the release team and a vote by the TSC.
https://docs.zephyrproject.org/latest/project/release_process.html#stabilization-phase