[lwip-users] Re: [lwip] Back again...

[Tim Kuik]

Adam,

What is the timetable for lwIP 0.6?

Tim

Adam Dunkels wrote:

> Hi all!
>
> Due to other work, I have been away from the lwIP mailing list for a while and
> am currently in the process of catching up a little with the messages. There
> are over 140 unread messages in my lwip folder right now! Hopefully I'll be
> able to go through most of them today.
>
> During my time off the list, I have been doing modifications to lwIP in
> preparation for a 0.6 version. Some of the changes are:
>
> --- General ---
> * The lwIP code has been too large for what it does. In the spririt of uIP,
> much of the code size can be reduced. I have been doing some of this already,
> especially with the TCP code.
> * A new example project, proj/minimal/, will show how to reduce lwIP to its
> minimum configuration (i.e., with no operating system support, small buffers,
> etc.).
> * A new API will be added to 0.6. This will be similar to how the uIP API
> works and will be in semantics as the raw API, but will not use separate
> callback functions for each event. It will use a single callback function
> that must be implemented by the application code. This is advantageous for
> those who will use lwIP to build another API on top of (similar to how Paul
> have been adding a socket layer on lwIP).
>
> --- ARP ---
> * Updated ARP implementation, with multiple queues for holding packets that
> are destined for addresses that are in the process of being resolved.
> * ARP implementation now does almost all Ethernet-related stuff, which greatly
> simplifies the device driver implementation.
>
> --- Memory management ---
> * Previously, the memory managers included reclaiming functionality. When
> memory was scarce, the memory managers called registered reclaimer functions
> that deallocated some memory. This didn't really work as intended, and it
> turns out that it is much simpler to let the calling module take care of the
> problem itself - thus, reclaiming functionality is gone.
> * The memp will be changed to macros instead of function calls. When
> statistics and debugging are turned off, the memp stuff will not produce any
> function calls at all.
> * A configuration option will be added to support other memory managers as
> well.
>
> --- Operating system support ---
> * The sys_arch stuff is not needed when lwIP is run as a single thread (either
> in a multitasking system or without an operating system). In 0.6 there will
> be an option to turn all sys_arch code off.
>
> --- IP ---
> * Support for IP fragment reassembly will be included in 0.6.
>
> --- TCP ---
> * Quite a lot has happened with the TCP code. Parts has been greatly
> simplified and variables that previously was passed as function arguments are
> now made global to save stack space and code size (on certain platforms).
> * TCP Urgent data will be supported in 0.6.
> * Better separation of input and output functionality - when an incoming
> segment is being processed, no data can be sent. Instead, when input
> processing is over, the output function is called to send data.
>
> That is the list of plans for 0.6. Hopefully, I didn't miss anything that I
> have intended to do.
>
> /adam
> --
> Adam Dunkels <address@hidden>
> http://www.sics.se/~adam
>
> [This message was sent through the lwip discussion list.]

[This message was sent through the lwip discussion list.]