[WIP, 1.9] Bootstrapping BSD Sockets like API

[pfalcon]

This shows the very initial steps on moving BSD Sockets API (prototyped out of tree) into the tree.

Things to decide/ack:

• Location. While later we may need tighter integration with subsys/net/ip/, so far everything fits nicely into subsys/net/lib/sockets/.
• Prefix to use for functions. As was discussed during RFC, there should be prefix, and optionally a header should #define pure POSIX names.
• Header name/location.
• Changes to net_context and friends. As can be seen, the only addition is a per-socket packet/connection queue. There's a recast of existing bit, and fairly speaking, I need to track more detailed context status, still looking how to do that, if anything there're whole 4 bytes of user_data pointer.

[pfalcon]

@jukkar , @tbursztyka , @Likailiu, @simple2017 , @mike-scott : Early comments are welcome.

[jukkar]

For the commit subject, I would prefer more logical naming like "net: socket: ...."
I usually try to avoid putting directory or file name into commit subject as files are moved around etc so better imho is to use logical component names here.

[jukkar]

I am fine with having a separate directory for this so we do not clutter subsys/net/ip too much.

[jukkar]

Better to use POINTER_TO_INT(ctx) here.

[pfalcon]

Fixed.

[pfalcon]

For the commit subject, I would prefer more logical naming like "net: socket: ...."

Fixed, thanks.

[nashif]

can you give an example where such namespace clashes might occur?

[pfalcon]

Sure, Zephyr is being used together with a 3rd-party library, whose authors also doubted that namespace clashes would occur, so used names like "listen" and "close" in their API ;-).

[nashif]

Can you give a specific example of such 3rd-party library? Not sure how we ever have 2 providers of bsd socket APIs, What libraries that potentially will be used with Zephyr would have implemented those APIs? This is in most cases implemented by the OS, not libraries.

[pfalcon]

An example is lwIP. Another example is someone finally addressing one of the big functionality holes of Zephyr - lack of native POSIX port.

Not sure how we ever have 2 providers of bsd socket APIs, What libraries that potentially will be used with Zephyr would have implemented those APIs?

I'm not sure either, and that's good indication that best practices of namespacing should be followed, otherwise we get a situation of a crowd where everyone considers oneself exceptional and that problems of everyone else doesn't apply to them, and if they happen, it's somebody else's chore to resolve them.

This is in most cases implemented by the OS, not libraries.

Zephyr is itself a library (libzephyr.a) which real applications (consisting of many other libraries) use to get some hardware abstraction and multitasking. Maybe in a couple of decades it'll become "the OS", but standing in a big-big crowd and pretending it's the only thing isn't the smoothest way to get there ;-).

Let's again take lwIP as an example. It defines 2 related config params:

#if LWIP_COMPAT_SOCKETS
#define accept(a,b,c)         lwip_accept(a,b,c)
#define bind(a,b,c)           lwip_bind(a,b,c)
...
#if LWIP_POSIX_SOCKETS_IO_NAMES
#define read(a,b,c)           lwip_read(a,b,c)
#define write(a,b,c)          lwip_write(a,b,c)
#define close(s)              lwip_close(s)
...
#endif
#endif

As the paragraph on which you comment describes, close() alone is enough to decide - it's irresponsible to grab that name for a code which doesn't do all that normal close() does, then it should be prefixed, then everything else should be prefixed for consistency.

[pfalcon]

Closing in favor of #498, which is resubmit of the complete patchset suitable for wide review. Hopefully, initial comments here were address and/or answered.