Re: BSD Sockets in mainline, and how that affects design decisions for the rest of IP stack (e.g. send MTU handling)

Boie, Andrew P

That's pretty much what I talked about - that with new requirements and
challenges, we may find out that a well-known and proven API like BSD Sockets
is a very good way to address them, instead of continuing to add complexity to
existing adhoc APIs.
What I stated is that when faced with an existing Zephyr API that works only in supervisor mode, rather than do a parallel implementation in user mode, first see if the C library already provides a suitable equivalent.
I don't know if this is a valid comparison to whatever your agenda is with BSD sockets API, my feeling is that it isn't, but at any rate I am strictly neutral on that matter. You need to talk to Jukka.

And above you write about protecting kernel from userspace, but is there a
requirement to protect one userspace entity (a thread in our case, as we don't
support processes) from another? I hope there's, because it doesn't make much
sense to go so long way of kernel vs userspace separation and don't think about
task separation. Just imagine that the could be a thread running OTA, and
another thread running an application level 3rd-party lib. We don't want
vulnerability in the latter to compromise OTA process.
You're not going to believe this, but we did actually consider this situation.
The memory domain APIs exist for this purpose. User threads otherwise only have access to their own stack. They are in-tree and documented, although only working on ARM at the moment.


Join to automatically receive all group messages.