Re: RFC: BSD Socket (like) API
Hello Luiz Augusto,toggle quoted messageShow quoted text
On Tue, 28 Mar 2017 23:34:25 +0300
Luiz Augusto von Dentz <firstname.lastname@example.org> wrote:
As I point in the reply to Leandro, these additions would be #ifdef'ednet_context). (We might need a queue per context to properlyIndeed we would have to put a queue per net_context which quickly adds
on CONFIG_NET_BSD_SOCKETS or something, so application developers will
have a choice whether save memory or have more familiar API. Putting
the queue, etc. into yet different structure (and waste some memory to
link this new structure to net_context) is yet another choice.
luckily we can use k_poll and avoid havingNote that the work I'm going to do is based on the previous experience
with implement BSD-Sockets like pull-style API on top of push-style
native ("raw") lwIP API. There, we were able to achieve that without
any threads (indeed, even with a cooperative RTOS underneath). So, no
planning of having extra threads on the initial stage of work
(push-to-pull "impedance conversion"). And presence of k_poll makes me
positive that we'll be able to implement even poll() or epoll() without
them (but that's 2nd stage of work).
But I guess the fundamental problem isAs my initial RFC message pointed, the initial target is MicroPython
with its "usocket" (micro-socket) module. That's a single app, but it
wraps a large chunk of BSD Sockets API for Python language. And of
course, this RFC is to see what other projects people are interested to
Well, I don't see how proper, configurable (on/off) layering worksCasting a pointer to an integer as suggested might work, but willWe can check if there are any paddings on net_context, if there is it
against the stack. I'd say, vice-versa, it allows to leverage it for
more usecases. Offloading, let me skip that part ;-).
as they either eat the available memory for enabling featuresLet users select whether they want to save memory or development
effort by using a conventional API ;-).
or reimplement part of the stack in other layers,Well, here I, as present at the mini-summit, can quote what Anas said
on this: he literally said - don't do that. If "higher level wrapper"
needs to reimplement or otherwise put upside-down what native layer
does, let's just rework native layer to be (more) POSIX/etc.
compatible. And well, that's pretty much how we already do it, with
several features for 1.7 done to make it closer to POSIX spirit, and
there're more such things in queue (here's the latest merged:
https://gerrit.zephyrproject.org/r/12455). So, no worries, or rather,
we all are aware of the problem, and ready to do homework on it.
not to mention this takes a lot of time that could be spend in otherAs a maintainer in other projects, I can easily relate to that thought
(that I, a maintainer, know better what contributors rather be working
on ;-) ). But here's how it works at Linaro: our aim is to reduce/avoid
fragmentation among ARM vendors (and not at the expense of more
fragmentation with other architectures). So if a member comes to us and
says "we'll use Zephyr if ...", we'd better listen, because there's no
lack of alternatives to Zephyr, and if interested parties select
something else instead, there won't be anything good from that to
Zephyr, or to the industry at all, which will continue in a chaos of
several dozens of adhoc (vs full-featured) RTOSes. And yeah, BSD
Sockets is a frequent request we heard for a while. Other things you
mention are in the plans (ours including) too.
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