RE : [lwip-devel] [task #7068] lwIP docs: Update, improve, add documentation about using lwIP

[Goldschmidt Simon]

I think the idea is good, we made some improvements and it's time
to release them to the public to prevent telling users 'use CVS head
If you want problems solved!'.

> >We should really talk about the new timers before releasing
> a new version, since that breaks compatibility!
> Yes (timers, with jiffies/ticks?). I also would like to 
> introduce "mutex" in sys_arch (since it's also break existing 
> ports). Your opinion?
> 

Hm, I don't know. Would it only be used for core-locking or also
for something else? Couldn't we solve that with binary semaphores
also? So that using mutexes would only be a plus to have better
responsiveness due to priority inversion?
I don't like the idea of needing semaphores AND mutexes as long
as it can be done different.

> >Checksum on copy is on the way, so that should make it into 
> a new release, too. 
> It depend of the time you need to check in it, you're the 
> only one to know that. More, it's an optimization...
> 

Yep, it is. But it could be a major optimization ;-)
After all, it's not that pressing, but there is an 'arch-dependent'
function in it: memcpy plus checksum generation depends even more
on a good code that fits the architecture than the 'checksum-only'
routine does!

> >Ip_frag changes should go in, too.
> Here, it's more a bug fix. It should be good to have it in 
> current release, no?
> 

Yep.

> >The rest of the tasks and most of the bugs can be delayed I think.
> Pretty agree, but I think we should check each one, and that 
> each active developer give his opinion. Kieran, I think you 
> should open a task like "lwIP 1.3.0 release" to talk about that.
> 

That would be good.

> What I would like to have closed before next release is:
> 
> bug #20429: Potential problem with IP Fragmentation and 
> TCPRetransmit bug #20318: api_msg "recv" callbacks don't call 
> pbuf_free in all error cases bug #20315: Problem in the use 
> of tcp_listen in api_msg.c

Yep

> bug #20288: event_callback is 
> called from multiple threads without locking

Would be good, should be easy to fix by looking at even_callback()
in sockets.c (maybe only add SYS_ARCH_PROTECT).

> bug #20287: 
> tcp_output_nagle sends too early

Yep.

> bug #20021: conn->sem is only signaled one-way

This is already fixed but needs some testing feedback.

> bug #19953: Bug in TCP State Machine - SYN_RCVD

Yep!

> bug #1902: Timeouts and semaphores/mailboxes are too 
> tightly integrated
> 

Dunno, I think this can only be 'solved' with core-locking:
I'd make the timeouts an extra task.
Maybe we should prevent application tasks from using our sys_arch
timeouts, that would be one improvement to keep users from
making the old mistake with one sys_arch_timeouts() per thread.


> task #6969: Review usage of conn->err in netconn layer
> 

Yep.

> And perhaps :
> patch #5741: bug in out of sequence queue processing - 
> incoming segment is larger than the old segment
> 

Would be good, but how to test it? We'd need a TCP-stack-test-framework.

> There is also some PPP specific problems:
> http://savannah.nongnu.org/patch/?5628
> http://savannah.nongnu.org/bugs/?17726 (same as previous)
> http://savannah.nongnu.org/bugs/?13315 (old, June 2005) I 
> sent an email to found a PPP developer, but no answers. So, 
> perhaps PPP is not something we can't maintain. Last user 
> which seems to be active on that (except Jonathan) is "Janusz 
> U". What do with PPP? Let it like this? Or...
>  

Or what? I'd suggest we leave it, since it 'kind of works', at least.
It's one of the things I have planned for the far future to test ppp
against a linux host running pppd, but it can take a (loooong) while
until I get there!


Simon