Re: RFC: BSD Socket (like) API
On Mon, 27 Mar 2017 09:29:31 +0200
Tomasz Bursztyka <email@example.com> wrote:
Hi Hughes,Please note that these names belong to LIBC namespace, not ZephyrI don't know Mynewt, but if I want BSD socket API in Zephyr, I would
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.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
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
One of Gil's point was that CC3200 native interface is exactly BSDOffloading is already handled through net_context, so it will
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.
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog