Are we sure this is a good idea? It is a very simplistic TCP/IP stack, great for small embedded projects ( I have used some earlier versions), but not sure it is good for a full blown OS. From the API description:
"The socket API is a compatibility API for existing applications,
currently it is built on top of the sequential API. It is meant to
provide all functions needed to run socket API applications running
on other platforms (e.g. unix / windows etc.). However, due to limitations
in the specification of this API, there might be incompatibilities
that require small modifications of existing programs.
** Threading
lwIP started targeting single-threaded environments. When adding multi-
threading support, instead of making the core thread-safe, another
approach was chosen: there is one main thread running the lwIP core
(also known as the "tcpip_thread"). The raw API may only be used from
this thread! Application threads using the sequential- or socket API
communicate with this main thread through message passing.
As such, the list of functions that may be called from
other threads or an ISR is very limited! Only functions
from these API header files are thread-safe:
- api.h
- netbuf.h
- netdb.h
- netifapi.h
- sockets.h
- sys.h
"
Does not seems like a good candidate to me. But I might be wrong, of course.
Are we sure this is a good idea? It is a very simplistic TCP/IP stack, great for small embedded projects ( I have used some earlier versions), but not sure it is good for a full blown OS. From the API description:
"The socket API is a compatibility API for existing applications,
currently it is built on top of the sequential API. It is meant to
provide all functions needed to run socket API applications running
on other platforms (e.g. unix / windows etc.). However, due to limitations
in the specification of this API, there might be incompatibilities
that require small modifications of existing programs.
"
Does not seems like a good candidate to me. But I might be wrong, of course.
Regards,
Jose
Well, perhaps if they take that and the existing code and rework it in the context of a full OS, maybe they will have something good. It seems if it was ready to go, it wouldn't need to be a GSOC project, since any developer could just plug it in and run with it. So it doesn't sound that straight forward to me.
Last edited by PurpleGurl on Tue May 03, 2011 11:13 pm, edited 1 time in total.
Well, reworking code that was designed with single thread in mind to be thread-safe can be a daunting task, often ending in a full re-write. I'm not familiar with the current tcp/ip stack in ROS, but would not something derivated from *BSD a better match?
It was already tried, the amount of changes needed for integration was also nearing a total rewrite. As seen here: http://www.sics.se/~adam/lwip/os.html lwIP is already made thread-safe.
hmm, my understanding is that for multithreaded environments, they just run the low level part of the stack in a separate thread, using a global mutex for access control. This could have performance scaling problems in multiprocessor systems.
In any case, it is not me who is going to do the job, so I guess I should shut up and let the developer to get on with it
This as well as buffer size, which was said also to cripple performance. Anyway, if it works (reliably) it would be a good temporary solution to fix up the rest of network stack, until a proper tcp driver is written. Its still a better stuff we have now.
