Re: RFC: BSD Socket (like) API

Paul Sokolovsky

Hello Tomasz,

On Mon, 27 Mar 2017 09:29:31 +0200
Tomasz Bursztyka <> wrote:

Hi Hughes,

I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:

1- Don’t keep POSIX names unless you are going to be POSIX
compliant. When running the system simulated, it’s often helpful to
use system sockets to communicate and do things, if you use POSIX
names you have conflicts.
1a- This also allows you to have a “true” POSIX mapping layer
on top, for people who have more memory and truly want socket-level

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
I don't know Mynewt, but if I want BSD socket API in Zephyr, I would
like to see no prefix in front of types and functions.
Sure, it's not going to be 100% Posix compliant, and it's not the
point here yes.

But I really want to use socket, bind, listen, as I mostly would in
any other OS.
Please note that these names belong to LIBC namespace, not Zephyr
namespace. So, in our case it's up to Newlib to define them in any it
wants (which is hopefully what we want). I think that good initial
target would be to have a compatibility headers, as I mentioned in
reply to Sterling:

#define socket net_sock_socket
#define listen net_sock_listen

(net_sock_ prefix is made and doesn't constitute any specific proposal
- so far).

For the FD, I hope we can make any struct pointer to look alike.
Maybe there are limitations however, not sure.
Right. There may be some limitation, but we should be good to start
with just casting structure pointers to integers and use that as
"socket identifiers". E.g. POSIX (via its publicly available SUSv2
rendition) says: "Otherwise
a value of -1 is returned and errno is set to indicate the error.". We
can easily provide that and thus be POSIX compliant.

However, we know that some real-world software likes to test for
negative return value instead:

int fd = socket(...);
if (fd < 0) ...

And indeed, the link above also says "Upon successful completion,
socket() returns a nonnegative integer, the socket file descriptor."
Well, that would be an example of limitation you talk about. But it's
my intuitive impression that majority (well, many) MCUs try to map
RAM/ROM into lower half/quarter of addresspace, so we should be good
here too, subject to actual checking over a long range of various

Anyway, I don't want to burden this initial discussion with narrow
issues like above, the point is that there're indeed may be some
limitations to consider, I have some inventory of them in my mind
already, ready to research more, and then will bring up at appropriate

3- Allow for multiple socket providers
that way it should be easy to “offload” the IP stack for cases
(e.g. WINC1500) where the IP stack is not on-chip, or where
somebody wants to use an existing commercial/industrial IP stack.
Offloading is already handled through net_context, so it will
seamlessly work already.
One of Gil's point was that CC3200 native interface is exactly BSD
Sockets. So, now he needs to convert that API to push-style native
Zephyr API. Then for this work, I will convert Z native push style to
pull style again. That would mean double "impedance conversion" for a
case like CC3200, and an idea to look if it's possible to avoid it. But
leave that topic to Gil, I'm not an offloading specialist.



Best Regards,
Paul | Open source software for ARM SoCs
Follow Linaro:!/linaroorg -

Join to automatically receive all group messages.