net: Namespace network symbols to avoid conflicts with Posix/libc #99169

jukkar · 2025-11-10T16:34:56Z

Rename network symbols i.e., add net_, NET_ or ZSOCK_ prefixes to those network symbols that can be found in Posix or libc. This way we can avoid circular dependency issues.

Fixes #97050

As midi2 is provided by networking subsystem it should not depend on any features provided by Posix. Convert Posix poll API calls to zsock poll ones. There is no functionality changes, only naming changes. Signed-off-by: Jukka Rissanen <[email protected]>

Rename network symbols i.e., add net_, NET_ or ZSOCK_ prefixes to those network symbols that can be found in Posix or libc. This way we can avoid circular dependency issues. Signed-off-by: Jukka Rissanen <[email protected]>

Allow user to continue use various network APIs without adding either net_, NET_ or ZSOCK_ prefixes. Signed-off-by: Jukka Rissanen <[email protected]>

The union field should not be named the same as the actual struct, otherwise we cannot implement the compatibility header file for network namespacing. So rename in_addr to __in_addr and in6_addr to __in6_addr fields. Signed-off-by: Jukka Rissanen <[email protected]>

Removing Posix header inclusion as networking APIs and code should be self contained now. Signed-off-by: Jukka Rissanen <[email protected]>

Do not include Posix header files inside network stack as we should not depend on Posix symbols in net stack. Signed-off-by: Jukka Rissanen <[email protected]>

Use namespaced network symbols in order to avoid circular dependency between Posix and network subsystems. Signed-off-by: Jukka Rissanen <[email protected]>

jukkar · 2025-11-10T16:37:16Z

Initial work on namespacing the network APIs, this is WIP. Creating a draft in order to get some faster CI runs than what I can do locally.
fyi: @aescolar / @rlubos / @cfriedt / @carlescufi

jukkar · 2025-11-10T16:42:38Z

Instructions for the reviewers. The main changes are in

include/zephyr/net/net_ip.h
include/zephyr/net/socket.h

The majority of the other changes are just to there to support the API naming changes.
The compatibility commit introduces a header file include/zephyr/net/net_compat.h that reverts the API changes so that we can do things in stages. This is controlled by a Kconfig option CONFIG_NET_NAMESPACE_COMPAT_MODE.

sonarqubecloud · 2025-11-10T16:44:48Z

Quality Gate failed

Failed conditions
E Reliability Rating on New Code (required ≥ C)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

cfriedt

Good work so far. I just left a couple of comments for non-sockaddr things. Although I'm sure you are already aware and planning for those too.

cfriedt · 2025-11-10T17:45:53Z

doc/connectivity/networking/api/coap_server.rst


    static int send_temperature(struct coap_resource *resource,
-                                const struct sockaddr *addr, socklen_t addr_len,
+                                const struct net_sockaddr *addr, socklen_t addr_len,


socklen_t should probably also be changed to uint32_t within the network subsystem.

I did not go that route, but just changed socklen_t to net_socklen_t. Not sure if we should do that uint32_t change as now it is easy to map the socklen variable between the network and Posix apis (because the naming is similar).
What other reviewers think about this, I am open to replace net_socklen_t if there are good arguments for it.

cfriedt · 2025-11-10T17:47:43Z

drivers/bluetooth/hci/userchan_bottom.c

 	addr.hci_channel = HCI_CHANNEL_USER;

-	if (bind(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
+	if (bind(fd, (struct net_sockaddr *)&addr, sizeof(addr)) < 0) {


Calls to bind() should also be replaced with zsock_bind() (unless being used via POSIX through a sample).

Similarly, connect(), close(), should be switched to zsock_connect(), zsock_close(), etc.

That file is for native_sim driver so I think I need to remove all the changes I did there.

cfriedt · 2025-11-10T17:50:26Z

drivers/bluetooth/hci/userchan_bottom.c

 	}

-	if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
+	if (connect(fd, (struct net_sockaddr *)&addr, sizeof(addr)) < 0) {


This should use zsock_connect()

cfriedt · 2025-11-10T17:51:09Z

drivers/ethernet/intel/eth_intel_igc.c

 {
 	struct net_eth_hdr *eth_hdr = (struct net_eth_hdr *)rx_buf;

 	switch (ntohs(eth_hdr->type)) {


we should have a non-POSIX version of ntohs() and others too.

Yes, I will change these. I started to change the source all over the code base but there was just so much of it, so I decided to concentrate my efforts first to subsys/net, tests/net and include/zephyr/net directories. Some of the drivers contain already changes and I will continue this work.

aescolar · 2025-11-11T08:34:55Z

drivers/usb/device/usb_dc_native_posix_adapt.c

 void usbip_start(void)
 {
-	struct sockaddr_in srv;
+	struct net_sockaddr_in srv;


This is also a native_sim bottom.

aescolar

Thanks @jukkar , overall it is looking good to me :)

aescolar · 2025-11-11T08:54:09Z

include/zephyr/net/net_compat.h

+#ifndef ZEPHYR_INCLUDE_NET_NET_COMPAT_H_
+#define ZEPHYR_INCLUDE_NET_NET_COMPAT_H_
+
+#if defined(CONFIG_NET_NAMESPACE_COMPAT_MODE)


I wonder should this ifdef be in include/zephyr/net/net_ip.h instead, and
should CONFIG_NET_NAMESPACE_COMPAT_MODE start being default y always?

Then The POSIX_API can include this header on its own from wherever it needs, and CONFIG_NET_NAMESPACE_COMPAT_MODE be switched to default n and deprecated(?)

That is certainly one option. The various Posix related symbols are now set in the compat header file, so we can keep it like that and just include this compat header in the Posix header files too. On the other hand Posix mandates that certain symbols are found in certain Posix header files, is it ok if we do not honor that but let network symbols be found in all the header files (by including the compat header)?

On the other hand Posix mandates that certain symbols are found in certain Posix header files, is it ok if we do not honor that but let network symbols be found in all the header files (by including the compat header)?

I guess ensuring that could be done with some future PR? meaning the posix api could first include this header to keep backwards compatibility, and later in a future PR it could split its content around in the proper headers.
Anyhow, no strong opinion from me, it just seemed like a simple/practical way to proceed retaining backwards compatibility.

aescolar · 2025-11-11T09:01:42Z

lib/posix/options/net.c

 }

-char *inet_ntoa(struct in_addr in)
+char *inet_ntoa(struct net_in_addr in)


I guess these (the signature of the shim functions the POSX API exposes) should remain the same?

jukkar added 7 commits November 10, 2025 14:53

net: Add network namespace compatibility header file

773c584

Allow user to continue use various network APIs without adding either net_, NET_ or ZSOCK_ prefixes. Signed-off-by: Jukka Rissanen <[email protected]>

net: socket: Network should not include any Posix header

952e5b8

Removing Posix header inclusion as networking APIs and code should be self contained now. Signed-off-by: Jukka Rissanen <[email protected]>

net: sockets: Remove Posix header file includes

1c40ba4

Do not include Posix header files inside network stack as we should not depend on Posix symbols in net stack. Signed-off-by: Jukka Rissanen <[email protected]>

lib: posix: net: Add support for namespaced network symbols

748c6c4

Use namespaced network symbols in order to avoid circular dependency between Posix and network subsystems. Signed-off-by: Jukka Rissanen <[email protected]>

jukkar added the In progress For PRs: is work in progress and should not be merged yet. For issues: Is being worked on label Nov 10, 2025

cfriedt reviewed Nov 10, 2025

View reviewed changes

aescolar reviewed Nov 11, 2025

View reviewed changes

net: Namespace network symbols to avoid conflicts with Posix/libc #99169

Are you sure you want to change the base?

net: Namespace network symbols to avoid conflicts with Posix/libc #99169

Conversation

jukkar commented Nov 10, 2025

Uh oh!

jukkar commented Nov 10, 2025

Uh oh!

jukkar commented Nov 10, 2025

Uh oh!

sonarqubecloud bot commented Nov 10, 2025

Quality Gate failed

Uh oh!

cfriedt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aescolar left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aescolar Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

aescolar left a comment •

edited

Loading

aescolar Nov 11, 2025 •

edited

Loading