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

[Frédéric BERNON]

>I don't like the idea of needing semaphores AND mutexes as long
>as it can be done different.

A future need will be to have a socket layer "extension" to enable to handle 
"inputs" like with RAWAPI. These callbacks could call lwip_send to response to 
"inputs", but with a LOCK based on semaphore, you will have a dead-locking 
since the callback has already "lock" the core, and lwip_send will do. With a 
mutex, no such problem. We could propose to "unlock" before calling the 
application callback, but in this case, you could be "interrupted" by another 
thread. That why I think it will be good to use mutex. More, if you have 
SYS_LIGHTWEIGHT_PROT=1, your sys_arch_protect is perhaps implemented on a mutex 
(since this call have to support recursive calls). Problem, with 
sys_arch_protect, you can't decide which "lock" you use...

>"lwIP 1.3.0 release"
Kieran, is it ok for you?

>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

I will propose a patch in "some" days

>PPP

Or... You could work on it !!! ;)

  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Goldschmidt Simon
Envoyé : mardi 10 juillet 2007 12:36
À : lwip-devel
Objet : RE : [lwip-devel] [task #7068] lwIP docs: Update, improve,add 
documentation about using lwIP



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


_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf