Why does CONFIG_POSIX_API enable experimental Kconfig items?

[droberson]

Hello,

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:

warning: Experimental symbol POSIX_ASYNCHRONOUS_IO is enabled.


warning: Experimental symbol POSIX_DEVICE_IO is enabled.


warning: Experimental symbol POSIX_FD_MGMT is enabled.


warning: Experimental symbol POSIX_MULTI_PROCESS is enabled.


warning: Experimental symbol POSIX_REALTIME_SIGNALS is enabled.


warning: Experimental symbol POSIX_SIGNALS is enabled.


warning: Experimental symbol NET_CONNECTION_MANAGER is enabled

After investigating, I see that CONFIG_POSIX_API enables experimental Kconfigs CONFIG_POSIX_FD_MGMT and CONFIG_POSIX_MULTI_PROCESS to name a few. See below for reference:

config POSIX_API
	bool "POSIX APIs"
	depends on !NATIVE_APPLICATION
	select NATIVE_LIBC_INCOMPATIBLE
	select POSIX_BASE_DEFINITIONS # clock_gettime(), pthread_create(), sem_get(), etc
	select POSIX_AEP_REALTIME_MINIMAL # CLOCK_MONOTONIC, pthread_attr_setstack(), etc
	select POSIX_NETWORKING if NETWORKING # inet_ntoa(), socket(), etc
	imply EVENTFD # eventfd(), eventfd_read(), eventfd_write()
	imply POSIX_FD_MGMT # open(), close(), read(), write()
	imply POSIX_MESSAGE_PASSING # mq_open(), etc
	imply POSIX_MULTI_PROCESS # sleep(), getpid(), etc
	help
	  This option enables the required POSIX System Interfaces (base definitions), all of PSE51,
	  and some features found in PSE52.

	  Note: in the future, this option may be deprecated in favour of subprofiling options.

Note in the above Kconfig definition:

imply POSIX_FD_MGMT # open(), close(), read(), write()
imply POSIX_MULTI_PROCESS # sleep(), getpid(), etc

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".

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

[Susheel Nuguru]

Good questions Derek,

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?

I think in Zephyr "imply" and "select" means different. imply means enabling but not necessarily enforcing it where as select forces the dependency to be enabled.

Since CONFIG_POSIX_API only implies experiemental configs, it did not inherit the experimental status.

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."

If I understand this right, CONFIG_POSIX_MULTI_PROCESS is enabled only for compatible reasons, some of the external libraries might might depend on the availability of these APIs like sleep, getpid. Not having the API available is bigger issue than getting a not implemented error code for those libraries depending on the availability of these features. So they are included for compatibility reasons, is my opinion. 

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.

I am not 100% sure if I can answer this properly since I do not have full overview of when the Zephyr community thinks that any particular feature is not experiemental anymore. This might be a question for the Zephyr community.

[droberson]

Hey Susheel,

Susheel Nuguru said:

I think in Zephyr "imply" and "select" means different. imply means enabling but not necessarily enforcing it where as select forces the dependency to be enabled.

My understanding is that "select" forces a Kconfig to be enabled, bypassing any dependency check within the selected Kconfig. "imply" enables a Kconfig so long as the dependencies within the Kconfig are met. Please correct me if I am wrong.

If my understanding is correct, both "select" and "imply" enable the specified Kconfig as detailed above. Thus, I don't really see how using "imply" for an experimental Kconfig would impact whether the Kconfig that used the "imply" (inherited it) is experimental or not. Just seems strange to me.

Susheel Nuguru said:

Not having the API available is bigger issue than getting a not implemented error code for those libraries depending on the availability of these features. So they are included for compatibility reasons, is my opinion. 

Since CONFIG_POSIX_API must be enabled, given that the description for CONFIG_POSIX_MULTI_PROCESS states that its use could lead to undefined behavior, is it safe for me to use CONFIG_POSIX_API in a commercial product? 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.

Susheel Nuguru said:

This might be a question for the Zephyr community.

Where is the appropriate forum for me to ask this question?

Thanks!

Derek

[Susheel Nuguru]

Please ask this here https://github.com/zephyrproject-rtos/zephyr/discussions as it is more relevant there. Nordic engineers can also answer there if they feel it relevant. 

[droberson]

Thanks Susheel,

I have asked my questions at the link below and will update this thread when I get additional clarification.

https://github.com/zephyrproject-rtos/zephyr/discussions/85336

Derek

[droberson]

+ Susheel Nuguru 

For anyone that comes across this thread, the Zephyr team replied with an answer on Github. The POSIX Kconfig "experimental" tags have been removed (fixed) and committed to the Zephyr trunk/main on Dec 19, 2024.

https://github.com/zephyrproject-rtos/zephyr/pull/83105

It appears this commit happened after Nordic compiled nRF Connect SDK 2.9.0. Thus, I imagine this fix will be rolled into the next nRF Connect SDK release.

However, CONFIG_POSIX_MULTI_PROCESS still has the following note in the latest Zephyr trunk:

Note: Currently Zephyr does not support multiple processes and therefore much of this option
group is not implemented and is considered undefined behaviour.

According to the Zephyr team, "It's not experimental in that functions have predictable results (typically something like setting errno to ENOSYS)". Thus, for any behavior that is not defined within these modules, your application will not go out to lunch unexpectedly, the modules will return an error code that you can then handle in your application thread. For more details, refer to the Github ticket linked above.

Summary: The CONFIG_POSIX experimental configurations identified in this ticket should be safe to use in the current SDK (2.9.0). The experimental tag should be removed in future SDK's.

Derek