Configuring with POSIX_API disables NET_SOCKETS_POSIX_NAMES

[SteveOss]

Describe the bug

If POSIX support is enabled with CONFIG_POSIX_API=y then use of POSIX compliant
network interface names with CONFIG_NET_SOCKETS_POSIX_NAMES is disabled. This seems illogical to me.

Expected behavior
Should be able to set both CONFIG_POSIX_API and CONFIG_NET_SOCKETS_POSIX_NAMES for maximum POSIX compliance.

Impact
Breaks existing build

Screenshots or console output

warning: NET_SOCKETS_POSIX_NAMES (defined at subsys/net/lib/sockets/Kconfig:16) was assigned the
value 'y' but got the value 'n'. You can check symbol information (including dependencies) in the
'menuconfig' interface (see the Application Development Primer section of the manual), or in the
Kconfig reference at

Environment (please complete the following information):

• OS: Linux
• Toolchain Zephyr SDK 0.10.1
• Commit 1.14 LTS branch

Additional context
Am pretty sure this used to work on 1.14, looks like has been broken on the LTS branch
at some point.

[aescolar]

CC: @pfalcon @jukkar

[jukkar]

Yes, this is a known issue. Can you try #17346 if it helps?

Edit: Just fyi, the issue was caused by this PR #16557

[SteveOss]

Will give it a try, but to me looks like a core configuration dependency issue. For NET_SOCKETS_POSIX_NAMES the dependency is:

!POSIX_API && NET_SOCKETS && NETWORKING

This just looks broken to me, to enable socket POSIX names, selecting POSIX APIs must be false ???
IMHO should be:

POSIX_API && NET_SOCKETS && NETWORKING or potentially just:

NET_SOCKETS && NETWORKING

[pfalcon]

This just looks broken to me, to enable socket POSIX names, selecting POSIX APIs must be false ???

No, you should just use POSIX APIs, period.

However, if you know what you're doing, and would like to munge with Zephyr's adhoc proprietary APIs, while making them to pretend to be POSIX-like, you may select a very special option NET_SOCKETS_POSIX_NAMES.

The current behavior works as intended. If it looks strange, then the strange thing is the use of NET_SOCKETS_POSIX_NAMES, not that it conflicts with POSIX_API.

[SteveOss]

The intent is to be able to compile code using standard POSIX and standard BSD networks calls e.g.

pthread_mutex_t mutex;
int sock = socket (AF_INET, SOCK_STREAM, 0);
pthread_mutex_init (&mutex, NULL);

Currently the catch 22 is that I have to enable POSIX_API to use the pthread stuff and enable
NET_SOCKETS_POSIX_NAMES to use the standard BSD socket calls. However enabling POSIX_API
disables NET_SOCKETS_POSIX_NAMES. For anyone attempting to port an existing application
to Zephyr this is the behaviour they want, the current configuration support appears to support either
POSIX or standard BSD network APIs, IMHO it should be possible to support both or am I missing
something ?

[SteveOss]

Oops have just read above log and see you guys already have the issue in hand.

[pfalcon]

The intent is to be able to compile code using standard POSIX and standard BSD networks

"Standard BSD networks" are part of "standard POSIX".

Currently the catch 22

The catch 22 is that Zephyr has severely broken POSIX subsystem, though some people are fixing it (while others are opposing streamlined progress in that direction).

Currently the catch 22 is that I have to enable POSIX_API to use the pthread stuff and enable
NET_SOCKETS_POSIX_NAMES to use the standard BSD socket calls.

No, POSIX_API enables all POSIX APIs. If you had to enable POSIX_API and NET_SOCKETS_POSIX_NAMES in some previous Zephyr version, that's the bug, which is being fixed.

For anyone attempting to port an existing application
to Zephyr this is the behaviour they want,

I'm one of the guys who work on porting existing apps to Zephyr, and speak from experience of doing that more than once (~3 porting projects by now).

the current configuration support appears to support either
POSIX or standard BSD network APIs, IMHO it should be possible to support both or am I missing
something ?

Once again, POSIX API does include BSD Socket API. However, the current POSIX support in Zephyr is severely limited and broken, and needs fixing to work as expected by "people who work on porting existing applications". There's WIP in that direction, which unfortunately, gets too much bikeshedding and sidetracking. Reversing it is however not an option (from my humble opinion as a POSIX subsys maintainer in Zephyr). Instead, interested parties should back and vote up the pending patches (https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Aopen+is%3Apr+label%3A%22area%3A+POSIX%22).

[SteveOss]

Am totally in support of implementing the correct fixes so that Zephyr has a quality POSIX API. Can
always macro my way round my current issues. No offence intended.