[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [lwip-devel] 1.3.0
From: |
Frédéric BERNON |
Subject: |
RE : [lwip-devel] 1.3.0 |
Date: |
Thu, 8 Nov 2007 09:40:28 +0100 |
I really would like to got a 1.3.0 release (my feeling is that lwIP release
time was too long between 1.2.0 and "1.3.0", of course, there was lot of
changes, but in a general way, I would be in favor of shorter release time).
But before release it, some records should be closed. Here the full list (hope
it will be readable), with MY point of view (it's not like this in the
bugtracker).
TASKS
#7421 Implement SO_RCVBUF
1.3.0
#7410 Don't include internal headers in api header files
1.3.0
#7244 Add sys_arch_ticks/jiffies in sys_arch
post-1.3.0
#7235 Create timeout framework for NO_SYS=1
1.3.0
#7212 Add Mutex concept in sys_arch
post-1.3.0
#7040 Work on tcp_enqueue
post-1.3.0
#7017 Implement DNS client
1.3.0
#7013 Create option to have all packets delivered to netif->output in one
piece post-1.3.0
#6995 Implement SO_REUSEADDR
post-1.3.0
#6969 Review usage of conn->err in netconn layer
1.3.0
#6930 Implement SO_LINGER
post-1.3.0
#6881 Create option to leave header fields in host byte order
post-1.3.0
#6849 Test how checksum on copy could be integrated into the stack
post-1.3.0
#6735 Provide new pbuf type: PBUF_RAM_NOCOPY
post-1.3.0
#6683 Document lwIPs thread safety requirements
could be closed (doc is an infinite task)
#1551 Make ARP more independent of interface hardware type
post-1.3.0
#1549 lwIP function documentation
could be closed (doc is an infinite task)
BUGS
#7040 Work on tcp_enqueue
#21535 Retransmit Timer in SYN_SENT state
post-1.3.0
#21494 TCP pcb->mss should be 536 if no MSS option received
1.3.0
#21492 TCP MSS can be larger than MTU
post-1.3.0
#21491 TCP MSS sent is based on the received MSS option
1.3.0
#21433 Calling mem_free/pbuf_free from interrupt context isn't safe
post-1.3.0
#21099 Request getting lost/unanswered in lwip stack [bug #20640]
post-1.3.0 (is it invalid or not?)
#21049 Allow reuse of pbufs after return from APIs
post-1.3.0
#20900 Potential crash error problem with netconn_peer & netconn_addr
1.3.0
#20779 Keep-Alive and SYNs
post-1.3.0
#20515 TCP delayed ack does not work as expected
post-1.3.0
#20511 No persist timer
post-1.3.0
#20287 tcp_output_nagle sends too early
post-1.3.0
#20199 TCP appears to be "Shrinking the Window"
post-1.3.0
#20155 select() with errorfd set
post-1.3.0
#19927 DHCP NACK problem
post-1.3.0
#19699 Bug in SNMP ASN1 decode; submitted patch
post-1.3.0
#13315 PPP PAP authentication can result in erroneous callbacks
post-1.3.0
#3031 Implement a new fully pool-based pbuf implementation.
Isn't it done???
PATCHS
#6253 Added csum to struct pbuf.
post-1.3.0
#5628 #17726 PPP: memory wasting with every reconnection by pppClose/SIG
post-1.3.0
Most of tasks/bugs I think we should integrate in 1.3.0 are already in
progress. Once again, it's my point of view.
In a flat view, I think we can group all these records like this:
"TCP"
#21535 Retransmit Timer in SYN_SENT state
#21494 TCP pcb->mss should be 536 if no MSS option received
#21492 TCP MSS can be larger than MTU
#21491 TCP MSS sent is based on the received MSS option
#21494 TCP pcb->mss should be 536 if no MSS option received
#21099 Request getting lost/unanswered in lwip stack [bug #20640]
#20779 Keep-Alive and SYNs
#20515 TCP delayed ack does not work as expected
#20511 No persist timer
#20287 tcp_output_nagle sends too early
#20199 TCP appears to be "Shrinking the Window"
"pbufs&driver"
#21433 Calling mem_free/pbuf_free from interrupt context isn't safe
#21049 Allow reuse of pbufs after return from APIs
#6735 Provide new pbuf type: PBUF_RAM_NOCOPY
#7013 Create option to have all packets delivered to netif->output in one
piece
#6849 Test how checksum on copy could be integrated into the stack
#6253 Added csum to struct pbuf
#3031 Implement a new fully pool-based pbuf implementation
"sys_arch"
#7244 Add sys_arch_ticks/jiffies in sys_arch
#7212 Add Mutex concept in sys_arch
"API"
#7421 Implement SO_RCVBUF
#7235 Create timeout framework for NO_SYS=1
#7017 Implement DNS client
#6995 Implement SO_REUSEADDR
#6969 Review usage of conn->err in netconn layer
#6930 Implement SO_LINGER
#20900 Potential crash error problem with netconn_peer & netconn_addr
#20155 select() with errorfd set
"Doc"
#6683 Document lwIPs thread safety requirements
#1549 lwIP function documentation
"Task,code in long long stand by"
#6881 Create option to leave header fields in host byte order
#1551 Make ARP more independent of interface hardware type
#19927 DHCP NACK problem
#19699 Bug in SNMP ASN1 decode; submitted patch
#13315 PPP PAP authentication can result in erroneous callbacks
#5628 #17726 PPP: memory wasting with every reconnection by pppClose/SIG
Last, for the release number, I'm in favor of 'lwIP 1.3.0'
====================================
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 David Empson
Envoyé : jeudi 8 novembre 2007 04:35
À : lwip-devel
Objet : Re: [lwip-devel] 1.3.0
Simon Goldschmidt <address@hidden> wrote:
> when did you plan to move on to 1.3.0? There are a couple of bugs
> open
> that are planned for 1.3.0, most of them are issues in the TCP part.
>
> As I don't see me having plenty of time to fix TCP bugs for the next
> months (since I have a 'real job', hehe - unfortunately, I'd love to work
> on those), I'd love to see 1.3.0 without the TCP fixes just to get a new
> release out with the numerous fixes 1.3.0 would include compared to
> 1.2.0!
If the TCP bugs are long standing, not easy to fix/test quickly, and fixing
them will not involve changing any of the APIs, then I agree: release 1.3.0
and defer fixing those bugs until (say) 1.3.1.
The primary goal should be to get everything done in one hit which will
require everyone to port LWIP back into their own implementations. API and
major structure changes are more difficult to deal with than LWIP internal
bug fixes.
If the TCP bugs will require API changes, then they should be fixed first,
or at least the required API changes should be done without fixing the bugs
(and without introducing new ones!), so 1.3.0 can be released.
Jared Grubb <address@hidden> wote:
> We could issue a "1.2.5" release based on the current head... Just an
> idea if there are still things we really want to finish for a 1.3.0
> release.
The degree of changes in the API suggest to me that this should be called
1.3.0 even if all the planned changes don't made it in. 1.2.5 implies that a
portion of the changes intended for 1.3.0 have been applied to the 1.2.0
code base and the differences have been kept to as few as possible. This is
not the case, in my opinion. It would be better to call this one 1.3.0 and
then do a 1.4.0 if there are further API changes.
_______________________________________________
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 : [lwip-devel] 1.3.0,
Frédéric BERNON <=