Re: [lwip-users] lwip request for comments

[Atte Kojo]

On Wednesday 23 November 2005 17:56, Christiaan Simons wrote:
> ====
> Some parts of the sequential API really need some cleaning up,

This response belongs actually to a previous post of yours, but I wanted to 
put everything on one response ;-). I also think that the sequential API 
should be ditched. There is nothing in it that the standard BSD socket API 
can't do except for zero-copy, and that can also be easily dealt with. The 
lwip socket API already uses zero-copy for UDP sockets and for TCP sockets it 
can be done with a new send flag, like MSG_NOCOPY.

The current lwip socket API also supports timeouts (using select()), which the 
sequential API doesn't.

> ====
> Other problems are in the cc.h "type system".
>
> 0. Some architectures do not have 8bit chars (some DSPs). Maybe others do
> not have 16bit words.

I for one am using lwip on a DSP with 24-bit chars (shorts, ints, pointers) 
and 48-bit longs. This required some changes to the protocol layers but now 
that they're dealt with, the stack works fine (wastes quite a bit of memory 
storing 8-bit values in 24-bit chars, but that was the easiest and fastest 
way).

> Most protocol headers rely on spefically sized fields, therefore the
> current "sized-type" system
> looks suitable to me. As a result we exclude some exotic architectures.

I dealt with this by using special functions for packing and unpacking 16- and 
32-bit data and then defining access macros for the packet headers using 
these functions. This requires the stack user to implement the pack/unpack 
functions, but makes other parts of the code more portable. I don't have a 
single ntoh/hton call in the stack because everything is being accessed 
through macro calls.

I also changed all the fields in the protocol structures to be u8_t arrays 
(for example u32_t foo -> u8_t foo[4]).

I wrote the pack/unpack functions in assembler so they shouldn't be any slower 
that the ntoh/hton-functions needed for little-endian machines anyway. 
Big-endian guys can just define these as simple typecasting macros.

I don't know how this would affect the users of the raw API, because I use the 
socket API. But I think this wouldn't affect people on the user side in any 
way. At least it shouldn't. Except that people using "exotic" architectures 
must remember to pack/unpack all their data.

-- 
Atte Kojo
Software Development Engineer
Elekta Neuromag Oy
Street address: Elimäenkatu 22, Helsinki, Finland
Mailing address: P.O. Box 68, FIN-00511 HELSINKI, Finland
Tel: +358 9 756 24084 (direct), +358 9 756 2400 (operator)
Fax: +358 9 756 24011
E-mail: address@hidden
www.neuromag.com