extmod vs modules in ports

[mvdw73]

I'm looking into the usocket module for the (non-mainline) Ameba port, and unfortunately the socket module for that port is very incomplete. I was going to use one of the other socket modules as a basis for fleshing it out, but I've found that the esp32 module has its own implementation of modsocket, while the RP2 port relies on the modsocket code in the extmod directory.

What mechanism makes the compilation "choose" the module in the port directory, vs choosing the one in the extmod directory, and how can i force the ameba port to use the one in the extmod directory?

I guess as importantly, is how can I ensure all the port-specific bits in the port socket module are taken care of if I manage to use the extmod module?

Without looking into the code too deeply yet, I'm guessing there's some calls into the hardware HAL/API in the module socket library, so I have to make sure the hardware is invoked correctly while trying to use the module.

I'd like to eventually remove most of the port modules that don't have a direct reference to actual hardware, and use the extmod modules as that seems like the best way to keep well maintained code going forward.

[jimmo]

In general, any LWIP-enabled port should be able to use extmod/modlwip.c to provide the socket module, and any port that uses the mod_network_nic_protocol_t interface should be able to use extmod/modsocket.c.

The three exceptions are:

• esp32: Even though it is technically, there are some IDF-specific things required. Much of this could be refactored into extmod/modlwip.c hopefully one day.
• unix: Provides its own BSD-sockets implementation.
• zephyr: Similarly, Zephyr-specific API.

I did actually recently re-implement the unix one on top of mod_network_nic_protocol_t but unfortunately the Unix socket module provides support for more features (e.g. unix domain sockets) so it doesn't fit into that API. I might still do it for Zephyr though.

To answer your question: extmod/modlwip.c and extmod/modsocket.c are always included in the build (either via extmod.mk or extmod.cmake), but it depends on the preprocessor options as to whether they actually do anything.

e.g. modsocket.c: #if MICROPY_PY_NETWORK && MICROPY_PY_SOCKET && !MICROPY_PY_LWIP
modlwip.c: #if MICROPY_PY_LWIP (this should probably be #if MICROPY_PY_NETWORK && MICROPY_PY_SOCKET && MICROPY_PY_LWIP` though!)

So on most ports they get this automatically by enabling the right options, but ESP32 is careful not to define MICROPY_PY_SOCKET or MICROPY_PY_LWIP and it puts its own modsocket.c into the build.