lwip request for comments

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

lwip request for comments

Christiaan Simons


Hi all,

====
API interference issue.

Some parts of the sequential API really need some cleaning up,
e.g. the SO_REUSE option stuff still breaks the raw-API.

This option was wrongly added to the transport layers,
while it should really reside in a higher (OS/process/thread aware) layer.

RFC:
If nobody objects I want to remove this SO_REUSE option from lwip/core.

====
Another problematic area is the PPP netif.

0. It doesn't follow lwip coding style in that it doesn't use the cc.h
types,
so you can't port it to 8 or 16 bit architectures whithout running into
trouble.

1. It won't build on a BSD host since it uses/redefines many standard BSD
headers.

It would suprise me if it actually runs without an OS,
one of the most important requirements for lwip/core components.
Maybe we need to be more verbose about this in our documentation.

RFC:
I would like to declare the PPP netif as "problematic / non-portable".
Maybe it needs to be moved to the contrib/ area, since it may work
on some targets, but not all of them. If anybody disagrees, or has better
ideas,
please speak up.

====
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.
 (VLIW hosts? On the other hand it would be silly using lwIP on a VLIW
machine...)

1. Most debugging code relies on "unsized" C (sn)printf formatters like
"%u" or "%d".

Some ugly typecasts (unsigned int) are already scattered through the
debugging lines
making it all less and less portable/readable.

RFC:
I would like to add "lwip specific formatters" (defines) to cc.h where the
porter is responsible
for defining the correct mapping between the typedefs and these fomatters.
This is to remove some needless typecasting, and when a cast is required,
we stick to the cc.h types.

(Most notably u8_t can't be (sn)printed without casting it.)

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.



Bye,

Christiaan Simons

Hardware / Software Engineer
Axon Digital Design

+31 (0)13 511 66 66
+31 (0)13 511 41 51

http://www.axon.tv



This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email]
www.neuromag.com


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users