[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : RE : [lwip-devel] [task #7068] lwIP docs: Update, improve, add docu
From: |
Frédéric BERNON |
Subject: |
RE : RE : [lwip-devel] [task #7068] lwIP docs: Update, improve, add documentation about using lwIP |
Date: |
Tue, 10 Jul 2007 14:45:32 +0200 |
>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
- RE : RE : [lwip-devel] [task #7068] lwIP docs: Update, improve, add documentation about using lwIP,
Frédéric BERNON <=