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: [EMAIL PROTECTED] www.neuromag.com _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
