lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] lwip request for comments


From: Christiaan Simons
Subject: [lwip-users] lwip request for comments
Date: Wed, 23 Nov 2005 16:56:12 +0100


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.





reply via email to

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