[lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING

[Jonathan Larmour]

Follow-up Comment #13, task #6994 (project lwip):

Frédéric Bernon wrote:
>>This is not the sockets API
> 
> Is what you say is that a handle can't be a pointer? Why? Is there lot of
> environements where "int" and "pointer" don't have same size ? Perhaps
some
> old ones?

In a standard BSD (or POSIX) sockets API, the "handles" are low numbered
integers. There are constraints on their maximum values - FD_SETSIZE and
OPEN_MAX at least. They can't be arbitrary values. In practice, they are
expected to be used in the implementation as the index to an array - usually
of generic file descriptors, but for lwIP that would be the struct
lwip_socket array.

>>then I don't think you should provide select() at all.
> 
> 
> Yes, I'm agree (to not provide select :) ). More, "select" is a part of
POSIX
> API, not of which is called Socket API.

I don't understand. The API is precisely based on the BSD style (now
standardised in POSIX) API, and lwIP includes the LWIP_COMPAT_SOCKETS option
precisely for the reason of providing something which is the BSD/POSIX
sockets API to ease porting of existing code. What "Socket API" are you
referring to? Microsoft only?

> Current "select" can't even be used
> with a real POSIX OS, since you can used in a same call a file (or a
serial
> port) and a socket.

Firstly, that's mainly because many embedded systems don't have file systems
(or they can be configured out). Even then, most people use select for
network operations, not file operations. Anyway, integrating lwIP sockets
into the OS select() call is beyond the scope of what we could ever expect
lwIP to do itself. As it happens, my employer has it on my plate some time in
the future to integrate lwIP into our OS's sockets API. That would undoubtedly
require changes in lwIP, but the details are entirely OS-specific and outside
of lwIP.

Additionally, you only get the select() definition if you include the lwIP
sockets API header. You don't have to do that in the same files as the ones
doing file operations. There's already a more common potential conflict with
the read() and write() functions in that respect.

To use my own example, there are quite a few people using lwIP under eCos.
With eCos you can use the full POSIX-style filesystem API, but you don't have
to - it's an optional component. Either way, you can use the network functions
in lwip/sockets.h directly (but if you do have the POSIX-style filesystem, not
in the same module).

But the point is that for those who are wanting to use select(), they expect
it to behave like select(). If you want to do something different, don't
mislead people by calling it select(). Or maybe implement poll() which fits
better with what you are wanting to do.

But it all seems like a lot of pain for users to save an array indirection.

>>I disagree strongly. People use it a lot. 
> 
> I'm not so sure than you, but, except ask to "all" users, I suppose it
could
> be difficult to change my (or your) point of view on that.

We have eCos users in the community, and the eCos operating system itself. We
have code that works with little modification on both lwIP and a "true" BSD
stack. This moves further and further away from that.
 
> Just to refresh some tips of that (since you perhaps don't have the time
to
> read all previous emails), there is two features:
> 
> - LWIP_TCPIP_CORE_LOCKING (which can be used with current
> socket/api_lib/api_msg) to avoid task switching by using a semaphore. 
> 
> - sockets2.c which need LWIP_TCPIP_CORE_LOCKING=1 and where the idea is to
> get something independant of netconn layer, directly based on raw-api.
This
> "task" is for that.

So what is this intended to achieve? Another API unique to lwIP that is not
BSD/POSIX and is in addition to the lwIP-specific netconn one?

What you're proposing at this point seems to be half way between the netconn
API and BSD sockets, but using the names of the BSD API functions.

> About the aim of this new sockets2.c file, the idea isn't to do the same
> thing than the current sockets.c one, but to propose an alternative (and
not
> to replace the current one).

I don't think we should have two "socket APIs", both with similar but
different semantics and API definitions. This would be a source of confusion
for users, maintenance overhead and a distraction for developers. Can't we
just as well improve the implementation behind the current APIs?

I think it would be best to understand that what's being worked on here is
the right approach in principle, before you spend too much time on it. If
there's a slight modification to the approach that will make the outcome
better, then that saves a lot, yes?

Jifl

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6994>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/