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

[Frédéric Bernon]

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

Interesting point of view, even if I don't share it on all the points.

I will try to do as short as possible (and sorry for my bad english). Most of
IP stacks providers give a socket api without any OS integration. So, when I
say "Socket API", don't think to Microsoft one (even if it's one of
possibility), but more to the generic API provided by any stack providers
(like Blunk, Fusion etc...).

I think that any "higher" integration with POSIX-IO functions like read,
write, close, select, etc... is outside the lwIP scope. That's why such
functions names can be disable to avoid conflict with unistd ones. Perhaps
select should also be in the LWIP_POSIX_SOCKETS_IO_NAMES part of sockets.h ?
Why not?

>...many embedded systems don't have file systems

many, but not all. Of course, mine got a flash file system, and can open file
from URL path, UNC path or local flash paths.

> Even then, most people use select for network operations, not file
operations

select can also be used to "route" data from a serial port to a network
socket for "full" duplex protocols implemented with one task. But I'm agree,
most of people mainly think to "select" for socket.

>With eCos you can use the full POSIX-style filesystem API, but you don't
have to - it's an optional component.

Yes, I know, I use eCOS on some projects, and there is lot of things to say
about eCOS... (good? things, of course ;) )

>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()

As I said, select is not (and perhaps will never be) supported in
sockets2.c.

>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 we have already improve the current design, but Simon, me (and some
others ?) would like to see a such new design for sockets API. In all cases,
since sockets2.c is based on rawapi, maintenance overhead is very low. So,
feel free to continue to improve socket/netconn layer if you want (and to use
it, of course). You will not to have to use sockets2.c (if you don't want).

>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? 

Measures I already did show that this new design give really better results
that current socket ones. That's why I think it "better" (more efficient and
simple).

One again, perhaps it will stay "outside" lwIP release. Currently, I "swap"
between sockets.c and sockets2.c (only with my makefile), without any
problems (on the UDP part). I just hope it could help some others developers
on their projects when it will be ready...

Thank you for your informations...


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/