lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Frédéric Bernon
Subject: [lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING
Date: Fri, 27 Jul 2007 16:00:33 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5

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

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

>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. 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. OS which want to support that have to got something like
a "IO layer" to abstract all "handles" type, and select have to be implement
at these layer. So, to my point of view, suchs POSIX-like calls have to be at
a "upper" level than the IP stack. I think there was a thread in the mailing
list about that (lwIP doesn't have to directly support POSIX calls like read,
write, etc...). lwIP integration in such OS, should be done with a
system-layer like (in pseudo-code):

read(handle)
  IO subsystem determine the IO driver to use
    IP stack IO driver
      lwIP's read

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

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.

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 even think it could be see like a big raw api
sample!!! Except netbuf part, the code is fully separate from current
sockets/api_lib/api_msg. It's currently a "draft" with some "dirty" hacks
(that's why I set it in "Private", and why it's not in CVS), and lot of
things have to be implement. I think to work on it this summer (on the
beach!!!). But except Simon and me, there is not lot of developers active on
that (snif). Perhaps, it will be something which finally will "live" outside
the official lwIP release, perhaps in a contrib module? I don't know...

Thank for your remarks.






    _______________________________________________________

Reply to this item at:

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

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]