Skip to content

RFC: Create a common usocket_mphal #4475

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Jongy opened this issue Feb 7, 2019 · 3 comments
Open

RFC: Create a common usocket_mphal #4475

Jongy opened this issue Feb 7, 2019 · 3 comments

Comments

@Jongy
Copy link
Contributor

Jongy commented Feb 7, 2019

We currently have 4 different modusocket implementations, all supposed to expose the exact same interface.

I believe lots of the code can be shared. There's lot of parameters handling and conversion between mp_obj_t to simple data types, and vice versa. Most of the systems do expose a BSD sockets API, or, at least, their API can be easily wrapped to achieve the BSD sockets API.

Having multiple implementations of the pythonic API is bad because things go wrong and little inconsistencies show up between different ports. Generally I think the pythonic API should be implemented only once, so having a file like utime_mphal.c is a nicer way.

Also, when the python API impl is done, it's easier to now implement it for more ports.

Would modusocket_mphal.c do it?
@Jongy Jongy mentioned this issue Feb 7, 2019
Closed
@dpgeorge
Copy link
Member

dpgeorge commented Feb 8, 2019

The problem with unifying the usocket implementations in that the ports usually have different underlying implementations with subtle differences that need to be accounted for. Currently there are 3 broad classes of usocket code:

  1. extmod/modlwip.c which directly wraps the low-level interface provided by lwIP, so that threads are not needed.
  2. Those based on BSD sockets, like in unix, esp32 and cc3200 ports. Note that cc3200 has some differences here to standard BSD sockets. It's possible that unix and esp32 usocket code could be combined.
  3. stm32 provides a separate general framework for plugging in external socket providers, eg cc3000 and wiznet (when the TCP/IP stack lives on the external device). This is similar to (2) above but goes through a dispatch layer so that multiple different BSD socket-like providers can be glued together.

If some kind of unification was done (which is a good thing to consider) then it would be very important to retain the efficiency of how (1) is currently implemented.

@dpgeorge dpgeorge closed this as completed Feb 8, 2019
@dpgeorge
Copy link
Member

dpgeorge commented Feb 8, 2019

Sorry, closed in error.

@dpgeorge dpgeorge reopened this Feb 8, 2019
@Jongy
Copy link
Contributor Author

Jongy commented Feb 9, 2019

I'll give it a shot while keeping in mind about efficiency and code size (which tend to get hurt while generalizing stuff). Start with something small and see if we find it useful.

@Jongy Jongy mentioned this issue Feb 18, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dpgeorge @Jongy