[ECOS] lwIP 1.3 port

[ECOS] lwIP 1.3 port

[Simon Kallweit]

Hi

I've invested a bit of time into porting lwIP 1.3 to eCos. I got a basic 
port up and running (using the synth ethernet driver). I have more or 
less completely rewritten the CDL script, having most of the lwIP 
configuration options in the CDL. I also adapted the system 
architecture, the tests, and changed some of the glue code. The glue 
code is where I'm not quite happy right now. lwIP offers two modes of 
operation, a single-thread model (using the event API) as well as a 
threaded model, using the sequential API (netconn or sockets). lwIP is 
primeraly used when resources are low, and the single-threaded model is 
the preferred mode of operation in that scenario. Let me outline what I 
have in mind for implementation, and let me know if you have any 
concerns, criticism or hints.

Multi-threaded operation:

In this mode, lwIP implicitly creates a thread called "tcpip" which 
basically processes incoming messages on an event queue. These events 
contain requests from the sequential APIs (netconn, sockets) as well as 
requests to process ethernet packets. The current eCos glue code adds 
another thread for ethernet packet delivery. All this thread does is 
waiting on a counting semaphore (posted by the ethernet drivers when 
packets arrive), receive the packets on reception, and post an event to 
the tcpip thread for processing. This model is quite wasteful on 
resources, as the two threads could probably be consolidated into one, 
but this would require changes in the lwIP code base, which I would like 
to avoid, so I guess the current model is OK.

Single-threaded operation:

In this mode, a single thread is used for all handling of the stack. In 
the current port, the user needs to initialize lwIP "by hand", setup 
timeouts etc. I would like to write some glue code to simplify usage of 
lwIP in this mode. The glue code should implement an initialization 
routine as well as the basic operation of the lwip thread (similar to 
what the tcpip thread in the threaded version provides). Basic timeouts 
of the protocols should automatically be handled when enabled in the 
configuration, and ethernet drivers should be polled. I would also like 
to integrate SLIP and PPP support. As these have to run in a separate 
thread (for serial communication), we need a simple queue to pass 
received packets to the main thread.

If this all sounds a big vague, I'm sorry, I'm just trying to lay it all 
out in my head. I guess I'll have to implement it and see where it goes. 
If anyone is interested in the current port, you can get it at 
https://hg.inthemill.ch/hg/ecos but it is all work in progress and 
subject to change.

Simon

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] lwIP 1.3 port

[Simon Kallweit]

>
> Single-threaded operation:
>
> In this mode, a single thread is used for all handling of the stack. 
> In the current port, the user needs to initialize lwIP "by hand", 
> setup timeouts etc. I would like to write some glue code to simplify 
> usage of lwIP in this mode. The glue code should implement an 
> initialization routine as well as the basic operation of the lwip 
> thread (similar to what the tcpip thread in the threaded version 
> provides). Basic timeouts of the protocols should automatically be 
> handled when enabled in the configuration, and ethernet drivers should 
> be polled. I would also like to integrate SLIP and PPP support. As 
> these have to run in a separate thread (for serial communication), we 
> need a simple queue to pass received packets to the main thread.

After some more thought, the single thread implementation does not seem 
to be that easy. The main reason is that I need SLIP and PPP, not 
necessarily ethernet. The current lwIP implementation of PPP and SLIP 
depend on multiple threads though. SLIP does blocking reads on the 
serial device and PPP requires the sys_timeouts from lwIP for timeout 
handling. I guess they can be adapted for single threaded operation, but 
not without touching the lwIP code obviously.

The SLIP code would have to be changed to non-blocking operation. This 
is rather simple. Porting PPP to single thread usage is rather a bit 
tricky though, but I still manageable. My current plan is to do the SLIP 
changes first, see how it works and then continue with PPP.

Is there anyone interested in testing or helping out?

Simon


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss