[riot-devel] Network API task force

Martine Lenders authmillenon at gmail.com
Fri May 8 10:58:05 CEST 2015

Hi Kaspar,
just to state the "opposite" opinion, too: while I see the need for an API
suitable for embedded use only and other stacks than the default one too,
I'm of the opinion, that the POSIX sockets (needed for library and
application ports) should also be as slim as possible. This means: A
wrapper (POSIX sockets) around a wrapper (the new new network API) around
some API (e. g. netapi) seems like overkill to me.


2015-05-08 10:18 GMT+02:00 Kaspar Schleiser <kaspar at schleiser.de>:

> Hi,
> at the last Network Stack Task Force meeting, we came to the conclusion
> that a task force for defining API's for network functionality like
> sockets or coap would be useful.
> So I'd like to start this and invite everyone to join!
> I'll start the discussion with my opinion on the need for a new socket API.
> It was discussed if we couldn't just adopt the BSD/POSIX socket API, as
> we would need that API anyways.
> In my opinion, it has some drawbacks for embedded usage. Best example:
> (From "man 7 socket"):
> --- snip ---
>        #include <sys/socket.h>
>        sockfd = socket(int socket_family, int socket_type, int protocol);
> --- snip ---
> This is the function that creates a socket and returns a handle. In
> malloc-capable systems, this is perfectly fine. In RIOT, the question
> arises, what does the returned fd mean?
> The socket will definately need some state. This needs to be somewhere
> in memory. Using that API, we'd need to either preallocate a certain
> amount of socket state structures, or use malloc. Both ways suck.
> So a new socket library might more look like:
> --- snip ---
> socket = socket(socket_t *sock, blah) ...
> --- snip ---
> That way, the caller has to provide all memory needed for managing the
> socket.
> We do it like that all over RIOT, so I'd like to see this adopted for
> sockets.
> I also believe that it is very easy to implement BSD sockets once these
> RIOT sockets are in place, adding the memory burden. It is not possible
> to do it the other way around...
> Thoughts?
> Kaspar
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150508/ddbacb2b/attachment.html>

More information about the devel mailing list