Re: RFC: BSD Socket (like) API


Paul Sokolovsky
 

Hello Sterling,

Thanks for the prompt feedback!

On Sun, 26 Mar 2017 09:37:07 -0700
"Sterling Hughes" <sterling@runtime.io> wrote:

+1

https://github.com/apache/incubator-mynewt-core/tree/develop/net/ip/mn_socket/include/mn_socket

I’d like to point to Mynewt’s socket APIs as a reference here, a
couple of things we considered:
Thanks for MyNewt references on the matter, I'll finally have a good
excuse to look into again (the time for which I couldn't find for a
while) ;-).


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.
Sure, the "BSD Sockets like API" functions would be still
prefixed/namespaced (I actually wanted to bring up a separate
discussion on namespacing of Zephyr APIs). Then if/when it reaches
enough parity that there could be a talk of porting existing apps with
minimal changes, there would be just a header with stuff like:

#define bind net_sock_bind

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
compatibility.

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
Agree. That was one of the 1st question I got at the minisummit, and my
answer was: "well, we could waste some memory by adding the FD table to
map small integers to underlying structures, but why?". Indeed, by just
casting pointers to integers, we can go a long, long way of using this
API and porting existing apps.

Generally, the work of adding well-known APIs is just a precursor (or
a subset) of implementing much bigger chunk of POSIX functionality and
making Zephyr much more POSIX compliant. So, I leave FDs introduction,
etc. to these later stages of work.

3- Allow for multiple socket providers
(https://github.com/apache/incubator-mynewt-core/blob/develop/net/ip/mn_socket/include/mn_socket/mn_socket_ops.h),
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.
Right. Our initial prototyping team here at Linaro consists of Gil
Pitney and me. Gil works on integrating TI CC3200 into Zephyr, and it
has networking offloading at many different levels, and the point is
exactly to consider whether it makes sense to consider offloading on BSD
Sockets API layer, in addition to various layers he already works on.
So, good point, and thanks for the pointer, we'll have a look how
MyNewt does that.

4- If you are interested in unifying this API with Mynewt, we’d be
happy to talk about agreeing on a unified API for sub-embedded
sockets.
I'll definitely have a look and see what commonality can be achieved,
hope Gil will provide feedback too.


Best,

Sterling

On 26 Mar 2017, at 9:06, Paul Sokolovsky wrote:

Hello,

Support for BSD Sockets API in Zephyr is one of the frequently asked
features from different parties. Possibility of such support was a
topic
of discussions at the recent OpenIoT Summit Portland and Zephyr
Mini-summit Budapest. I'm happy to report that I didn't hear a
single "cons" vote, most people I heard or talked with were
positive that they
either interested in it themselves, or it least OK with it if it's
properly layered and doesn't bloat existing networking API.

So, based on that, Linaro Zephyr team would like to proceed with
bootstrapping work on this, collecting initial requirements, and
starting prototyping. I submitted a Jira Epic
https://jira.zephyrproject.org/browse/ZEP-1921 for this feature,
which has a detailed, even if maybe somewhat unstructured
discussion of initial ideas/requirements.

I won't paste it here, instead inviting interested parties to read
it there. Instead, here's a summary of the initial ideas:

1. There's no talk about implementing complete 100% (or 99.9%) POSIX
compliant sockets API. We may get there eventually, but that would
require stakeholders for each expensive or hard to implement
feature. The current approach is that we value lightweight nature
of Zephyr, and
looking towards finding a minimal set of changes (additions) to
provide
BSD Sockets *like* API to Zephyr.

2. The specific featureset of the initial interest is as follows.
The current Z networking API is push-based, where the OS pushes
data into an application (via a callback). Whereas BSD Sockets API
is pull-based,
where an application asks OS for new data to process, when an
application feels like. Implementing this pull-style API is the
initial focus of the effort.

3. The work is going to be guided by porting efforts of an actual
application which needs BSD Sockets API (MicroPython). That would
serve
as an initial (out-of-tree) prototype, with relevant code to be
optimized and merged in-tree for wider reuse.


Consequently, questions to the Zephyr community:

1. Are you interested in BSD Sockets like API?
2. Does the plan above sound good? Any important points to take
care of right from the beginning?
3. Or would you do something differently?
4. Any other feedback is appreciated.



Thanks,
Paul

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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


--
Best Regards,
Paul

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

Join devel@lists.zephyrproject.org to automatically receive all group messages.