posix: options: don't imply POSIX_MESSAGE_PASSING

[JordanYates]

Don't imply POSIX_MESSAGE_PASSING when POSIX_API=y as this option has a non-trivial RAM implication in HEAP_MEM_POOL_ADD_SIZE_MQUEUE.

The mq_* API is minimally used in-tree, with all users already enabling the symbol directly.

POSIX_API is selected by WIFI_NM_WPA_SUPPLICANT, and since the Wi-Fi supplicant users are huge RAM hogs, any savings are appreciated.

[JordanYates]

Looking into this a bit more, should POSIX_API be selecting any symbols at all? There are all these nice options for selecting various feature subsets, but POSIX_API is just selecting huge chunks by default (POSIX_BASE_DEFINITIONS, POSIX_AEP_REALTIME_MINIMAL, etc). To me it seems like it should be more like:

config POSIX_API
  bool "POSIX APIs"
  help
    Parent symbol

choice POSIX_AEP_CHOICE
  depends on POSIX_API
  default POSIX_AEP_CHOICE_BASE

...
endchoice

[cfriedt]

Looks good to me.

Actually, the "default number of things" that we have do not necessarily need to align with the POSIX spec (by default). That's the nice thing about them being made configurable. As long as the config system, feature macro system, sysconf, etc, are able to change and convey what the value is, the application can make an informed decision. If something needs to be to spec, it can be.

So the heap-add by message passing as well as the heap-add by pthreads can even be further reduced by reducing the default number of things (just in general, not needed in this pr of course). Just saying a lot of this is ripe for space optimization.

Since the message passing option has been linked to the correct option group (xsi realtime), and since many other deprecated symbols are now gone (e.g. non-standard pthread IPC), it makes sense to remove it from POSIX API (which can be repurposed as since it is non-standard).

Thanks - it's a definite improvement

[cfriedt]

Looking into this a bit more, should POSIX_API be selecting any symbols at all?

That's exactly the point - it was this blanket, non-standard option that just kept growing, and was basically around to support deprecated options that are now gone.

AFAIR, also most in-tree usage of POSIX_API should be removed or easily replaceable now with better choices.

Can choice options can depend on regular options?

As far as AEP choices go, why don't we create another AEP choice that selects only POSIX_LIBC_EXT (which Zephyr has already chosen to use by default), and then make that the default AEP choice?

[JordanYates]

AFAIR, also most in-tree usage of POSIX_API should be removed or easily replaceable now with better choices.

Right now, POSIX_API is required to access the posix headers without the Zephyr prefix, which is required for some third-party libraries.

Can choice options can depend on regular options?

Yes? Although I'm not sure what sort of option construction you are thinking of.

As far as AEP choices go, why don't we create another AEP choice that selects only POSIX_LIBC_EXT (which Zephyr has already chosen to use by default), and then make that the default AEP choice?

I know almost nothing about the posix specification and what makes sense from that perspective, if you think its a good idea then sure.

[cfriedt]

POSIX_C_LANG_SUPPORT_R is also chosen to be used by default in Zephyr, so that would be a part of whatever goes into the new AEP default choice.

However, C lang r is incorrectly lumped in to _POSIX_THREAD_SAFE_FUNCTIONS right now, which is an Option rather than an Option Group. It needs to be broken up.

Luckily, most of the work to correct that has already been done in #83368 .

[cfriedt]

AFAIR, also most in-tree usage of POSIX_API should be removed or easily replaceable now with better choices.

Right now, POSIX_API is required to access the posix headers without the Zephyr prefix, which is required for some third-party libraries.

We should make that a separate Kconfig option, since it mainly relates to build options.

Can choice options can depend on regular options?

Yes? Although I'm not sure what sort of option construction you are thinking of.

I was under the impression that they couldn't. Or maybe it's just that choice symbols can't be selected by options.

Either way, I think reducing the creep of POSIX options is pretty feasible shortly, and it can be done in a standards-friendly way.

[JordanYates]

I've done a test PR of removing all the defaults features enabled to see how much breaks: #88541