Why does CONFIG_POSIX_API enable experimental Kconfig items?

[droberson-ds]

Hello,

I was told to ask my questions here. They were originally asked on the Nordic Devzone here: https://devzone.nordicsemi.com/f/nordic-q-a/118626/why-does-config_posix_api-enable-experimental-kconfig-items

To preface:

• HW: nRF9151DK
• SDK/Toolchain: nRF Connect SDK v2.9.0
• I am new to Zephyr (first project)

When using a nRF91 modem, it seems that CONFIG_POSIX_API is used by the samples included with the nRF Connect SDK. Even the Developer Academy courses use the POSIX sockets API. Upon enabling the configuration that notifies you of when experimental Kconfigs are used, I see a bunch in the build log. Seme of which are CONFIG_POSIX_FD_MGMT and CONFIG_POSIX_MULTI_PROCESS.

Question 1: If CONFIG_POSIX_API is not marked as "experimental", but enables other experimental Kconfigs, then shouldn't CONFIG_POSIX_API be experimental by inheritance?

Question 2: Why does CONFIG_POSIX_API enable POSIX_MULTI_PROCESS if the description for POSIX_MULTI_PROCESS says "Note: Currently Zephyr does not support multiple processes and therefore much of this option group is not implemented and is considered undefined behaviour."

I don't want to use anything that could result in "undefined behavior". Is it safe to disregard this warning?

Some product certification bodies such as FDA have guidelines on not using "experimental" libraries from my understanding. If experimental libraries are used, you must provide a risk assessment and mitigation plan for any potential issues as it relates to cybersecurity, public safety, etc.

Question 3: Why are the POSIX Kconfigs used for modem libraries in numerous SDK revisions still experimental? They have been around since the nRF9160 from what I understand (please correct me if I am wrong). Seems like whatever Kconfigs needed for cellular communication would have matured and should no longer be experimental.

Thanks,

Derek

[nashif]

@cfriedt FYI

[cfriedt]

Fairly certain that @rlubos fixed this in #83105.

[cfriedt]

Deviations from the POSIX spec are mostly documented and we use the term "undefined behaviour" somewhat liberally because it's recognized terminology and is admissable according to the spec.

The eventual goal is to reduce or eliminate UB.

It's not experimental in that functions have predictable results (typically something like setting errno to ENOSYS), but the behaviour is not defined by the POSIX spec in those cases.

I hope that helps to make some sense of it.

[droberson-ds]

Ok, it's good to know that these library functions have predictable results and won't send my application out to lunch unknowingly.

However, since these libraries are layered, am I to assume that the lower layers will bubble up the errno to ENOSYS results so I can handle them accordingly in my application thread? Ie, will my thread be notified of this undefined behavior, so I can take a corrective action?

Thanks,

Derek

[cfriedt]

Yes

[droberson-ds]

Thank you for your support and clarification! It is much appreciated.

Derek

[cfriedt]

Happy to help 😄