* lwip 1.3.2 port [not found] ` <73f9997f1001220342h7bc1c79cl7180a184bee867f3@mail.gmail.com> @ 2010-01-22 12:54 ` Simon Kallweit 2010-01-22 13:31 ` John Dallaway 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2010-01-22 12:54 UTC (permalink / raw) To: ganesh kr, John Dallaway; +Cc: eCos developers Hi John, Hi Ganesh Nice to hear that you are using the lwip stack and it is working fine for you. Currently, I hold the lwip code in my own git repo, shared with other changes I have done to eCos. The plan was to get my current lwip code into the CVS. John, I think it's about time to get this done. I can do one latest merge with the lwip 1.3.2 codebase and then we should be ready. I still have some local changes concerning ppp in my repo (which are absolutely necessary in my current project). But I think we should keep these changes in for a while. It seems like some work is done in the official lwip repo, concerning ppp. But these changes will only be available in future 1.4.x releases. The current stable release is 1.3.2, and will be for a little while. When we get to a stable 1.4.x release, it may be a good time to get back to the lwip repositories ppp code. In the meanwhile, I'll keep track of what's happening in the official repo and try to incorporate my changes into the official repo (support for ppp in a single-threaded lwip environment). What do you think? Simon ganesh kr wrote: > Hi Simon, > > I am using the lwip 1.3.0 stack ported to ecos 3.0 by you for the last > 4-5 monts and is working fine. Thanks for that. I have some questions: > 1. Are you keeping it in any repository so that I can take the latest > one? The one which I am using is lwip-20090722.tar.gz > 2. What I need to do to keep the codebase provided by you to be in > sync with the latest developments/fixes heppening in lwip1.3.0 > > Regards, > Ganesh K R > > On Wed, Jul 22, 2009 at 4:58 PM, Simon Kallweit > <simon.kallweit@intefo.ch> wrote: >> ganesh kr wrote: >>> Hi, >>> >>> I am new to ecos. I have 258 KB flash on my board. I am able to build >>> and run my small appliaction with ecos + lwip as nw stack. the code >>> size is 69KB. >>> I want to switch to freebsd/ openbsd based nw stack so that I can use >>> SNMP and DNS. Please any one let me know the aproximate code siaze if >>> I use freebsd based nw stack. >> I don't have much experience with the other stacks (using lwip myself) but >> you need plenty of RAM to use them, which could be a problem on your >> platform. lwip does have support for DNS and SNMP, the APIs just differ. You >> could check out my current lwip port, which is a lot more up to date than >> the one in the eCos repository: >> >> http://download.westlicht.ch/lwip-20090722.tar.gz >> >> Simon >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-22 12:54 ` lwip 1.3.2 port Simon Kallweit @ 2010-01-22 13:31 ` John Dallaway 2010-01-22 14:43 ` Simon Kallweit 0 siblings, 1 reply; 11+ messages in thread From: John Dallaway @ 2010-01-22 13:31 UTC (permalink / raw) To: Simon Kallweit; +Cc: ganesh kr, eCos developers Hi Simon Simon Kallweit wrote: > Hi John, > Hi Ganesh > > Nice to hear that you are using the lwip stack and it is working fine > for you. Currently, I hold the lwip code in my own git repo, shared with > other changes I have done to eCos. The plan was to get my current lwip > code into the CVS. John, I think it's about time to get this done. I can > do one latest merge with the lwip 1.3.2 codebase and then we should be > ready. > > I still have some local changes concerning ppp in my repo (which are > absolutely necessary in my current project). But I think we should keep > these changes in for a while. It seems like some work is done in the > official lwip repo, concerning ppp. But these changes will only be > available in future 1.4.x releases. The current stable release is 1.3.2, > and will be for a little while. When we get to a stable 1.4.x release, > it may be a good time to get back to the lwip repositories ppp code. In > the meanwhile, I'll keep track of what's happening in the official repo > and try to incorporate my changes into the official repo (support for > ppp in a single-threaded lwip environment). > > What do you think? Sounds good to me. Please let me know when your final lwIP 1.3.2 tarball is available for download/review. John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-22 13:31 ` John Dallaway @ 2010-01-22 14:43 ` Simon Kallweit 2010-01-22 18:51 ` John Dallaway 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2010-01-22 14:43 UTC (permalink / raw) To: John Dallaway; +Cc: ganesh kr, eCos developers John Dallaway wrote: > Hi Simon > > Simon Kallweit wrote: > >> Hi John, >> Hi Ganesh >> >> Nice to hear that you are using the lwip stack and it is working fine >> for you. Currently, I hold the lwip code in my own git repo, shared with >> other changes I have done to eCos. The plan was to get my current lwip >> code into the CVS. John, I think it's about time to get this done. I can >> do one latest merge with the lwip 1.3.2 codebase and then we should be >> ready. >> >> I still have some local changes concerning ppp in my repo (which are >> absolutely necessary in my current project). But I think we should keep >> these changes in for a while. It seems like some work is done in the >> official lwip repo, concerning ppp. But these changes will only be >> available in future 1.4.x releases. The current stable release is 1.3.2, >> and will be for a little while. When we get to a stable 1.4.x release, >> it may be a good time to get back to the lwip repositories ppp code. In >> the meanwhile, I'll keep track of what's happening in the official repo >> and try to incorporate my changes into the official repo (support for >> ppp in a single-threaded lwip environment). >> >> What do you think? > > Sounds good to me. Please let me know when your final lwIP 1.3.2 tarball > is available for download/review. Ok, I merged the 1.3.2 stable code and did a few quick tests (the changes are not huge). The tarball is at http://download.westlicht.ch/lwip-20100122.tar.gz Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-22 14:43 ` Simon Kallweit @ 2010-01-22 18:51 ` John Dallaway 2010-01-23 11:57 ` Simon Kallweit 0 siblings, 1 reply; 11+ messages in thread From: John Dallaway @ 2010-01-22 18:51 UTC (permalink / raw) To: Simon Kallweit; +Cc: eCos developers Hi Simon Simon Kallweit wrote: > Ok, I merged the 1.3.2 stable code and did a few quick tests (the > changes are not huge). The tarball is at > http://download.westlicht.ch/lwip-20100122.tar.gz Some initial comments based mainly on diffs against the upstream lwIP 1.3.2 sources and the eCos lwIP 1.1.1 port: a) On the whole, the upstream sources have very little modification. That's good news for future updates. Is it strictly necessary to move the include/ipv4/ headers into include/ as part of the eCos port? This seems like unnecessary effort and will also make it more difficult to support IPv6 in the future. b) Closure of the extern "C" block seems to be missing in network.h. c) There are a lot of small changes under src/netif/ppp/ including function renaming. I understand that you have your own PPP requirements to consider but I think we should stick closer to the master sources for the CVS check-in. Unless your changes have already been accepted upstream? I hope to look at the CDL and run up some tests over the weekend. John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-22 18:51 ` John Dallaway @ 2010-01-23 11:57 ` Simon Kallweit 2010-01-23 14:04 ` John Dallaway 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2010-01-23 11:57 UTC (permalink / raw) To: John Dallaway; +Cc: eCos developers John Dallaway schrieb: > Hi Simon > > Simon Kallweit wrote: > > >> Ok, I merged the 1.3.2 stable code and did a few quick tests (the >> changes are not huge). The tarball is at >> http://download.westlicht.ch/lwip-20100122.tar.gz >> > > Some initial comments based mainly on diffs against the upstream lwIP > 1.3.2 sources and the eCos lwIP 1.1.1 port: > > a) On the whole, the upstream sources have very little modification. > That's good news for future updates. Is it strictly necessary to move > the include/ipv4/ headers into include/ as part of the eCos port? This > seems like unnecessary effort and will also make it more difficult to > support IPv6 in the future. > I'll see if we can change that. But I think we can still leave out the IPv6 code, right? > b) Closure of the extern "C" block seems to be missing in network.h. > Ok. > c) There are a lot of small changes under src/netif/ppp/ including > function renaming. I understand that you have your own PPP requirements > to consider but I think we should stick closer to the master sources for > the CVS check-in. Unless your changes have already been accepted upstream? > Well, yesterday night I have checked the lwip HEAD, and it looks like there has been lots of work done in the ppp departement. It now supports polling and multi-threaded support out of the box. So it might be considerable to directly use the current HEAD for inclusion into eCos and keep it updated with the lwip repository until we hit the next stable release. Backporting the ppp changes to the 1.3.2 codebase is a bit troublesome as the internal timeout framework has changed a bit and we would have to backport this too. I would pledge for the use of the 1.4.0 development tree. What do you think about this? Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-23 11:57 ` Simon Kallweit @ 2010-01-23 14:04 ` John Dallaway 2010-01-23 15:46 ` Simon Kallweit 0 siblings, 1 reply; 11+ messages in thread From: John Dallaway @ 2010-01-23 14:04 UTC (permalink / raw) To: Simon Kallweit; +Cc: eCos developers Hi Simon Simon Kallweit wrote: > John Dallaway schrieb: >> Hi Simon >> >> Simon Kallweit wrote: >> >>> Ok, I merged the 1.3.2 stable code and did a few quick tests (the >>> changes are not huge). The tarball is at >>> http://download.westlicht.ch/lwip-20100122.tar.gz >>> >> >> Some initial comments based mainly on diffs against the upstream lwIP >> 1.3.2 sources and the eCos lwIP 1.1.1 port: >> >> a) On the whole, the upstream sources have very little modification. >> That's good news for future updates. Is it strictly necessary to move >> the include/ipv4/ headers into include/ as part of the eCos port? This >> seems like unnecessary effort and will also make it more difficult to >> support IPv6 in the future. > > I'll see if we can change that. Looking at this in more detail, it appears that the only way to preserve the upstream directory layout would be to add "-I$(PREFIX)/include/ipv4" to CYGBLD_GLOBAL_CFLAGS. Otherwise, other eCos packages will not find the IPv4-specific headers when #including netif.h (for example). Perhaps it is better to move the IPv4 header files as you have done already. We can think again for a future lwIP import if the IPv6 support moves beyond "experimental" status. >> c) There are a lot of small changes under src/netif/ppp/ including >> function renaming. I understand that you have your own PPP requirements >> to consider but I think we should stick closer to the master sources for >> the CVS check-in. Unless your changes have already been accepted >> upstream? > > Well, yesterday night I have checked the lwip HEAD, and it looks like > there has been lots of work done in the ppp departement. It now supports > polling and multi-threaded support out of the box. So it might be > considerable to directly use the current HEAD for inclusion into eCos > and keep it updated with the lwip repository until we hit the next > stable release. Backporting the ppp changes to the 1.3.2 codebase is a > bit troublesome as the internal timeout framework has changed a bit and > we would have to backport this too. I would pledge for the use of the > 1.4.0 development tree. What do you think about this? We always seem to be waiting for the next version of lwIP. :-) At this stage, I would favour an initial check-in of something close to lwIP 1.3.2 followed by an update of the PPP code from the lwIP HEAD as time permits. John Dallaway ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-23 14:04 ` John Dallaway @ 2010-01-23 15:46 ` Simon Kallweit 2010-01-25 11:44 ` John Dallaway 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2010-01-23 15:46 UTC (permalink / raw) To: John Dallaway; +Cc: eCos developers John Dallaway schrieb: > Hi Simon > > Simon Kallweit wrote: > > >> John Dallaway schrieb: >> >>> Hi Simon >>> >>> Simon Kallweit wrote: >>> >>> >>>> Ok, I merged the 1.3.2 stable code and did a few quick tests (the >>>> changes are not huge). The tarball is at >>>> http://download.westlicht.ch/lwip-20100122.tar.gz >>>> >>>> >>> Some initial comments based mainly on diffs against the upstream lwIP >>> 1.3.2 sources and the eCos lwIP 1.1.1 port: >>> >>> a) On the whole, the upstream sources have very little modification. >>> That's good news for future updates. Is it strictly necessary to move >>> the include/ipv4/ headers into include/ as part of the eCos port? This >>> seems like unnecessary effort and will also make it more difficult to >>> support IPv6 in the future. >>> >> I'll see if we can change that. >> > > Looking at this in more detail, it appears that the only way to preserve > the upstream directory layout would be to add "-I$(PREFIX)/include/ipv4" > to CYGBLD_GLOBAL_CFLAGS. Otherwise, other eCos packages will not find > the IPv4-specific headers when #including netif.h (for example). Perhaps > it is better to move the IPv4 header files as you have done already. We > can think again for a future lwIP import if the IPv6 support moves > beyond "experimental" status. > Ok, now I remember why this was necessary :) > >>> c) There are a lot of small changes under src/netif/ppp/ including >>> function renaming. I understand that you have your own PPP requirements >>> to consider but I think we should stick closer to the master sources for >>> the CVS check-in. Unless your changes have already been accepted >>> upstream? >>> >> Well, yesterday night I have checked the lwip HEAD, and it looks like >> there has been lots of work done in the ppp departement. It now supports >> polling and multi-threaded support out of the box. So it might be >> considerable to directly use the current HEAD for inclusion into eCos >> and keep it updated with the lwip repository until we hit the next >> stable release. Backporting the ppp changes to the 1.3.2 codebase is a >> bit troublesome as the internal timeout framework has changed a bit and >> we would have to backport this too. I would pledge for the use of the >> 1.4.0 development tree. What do you think about this? >> > > We always seem to be waiting for the next version of lwIP. :-) > True, true. But, with the original 1.3.2 lwip code, ppp can only be used in a multi-threaded environment. I'd have to adapt the CDL etc. for the vanilla 1.3.2 codebase and could not use it in my own projects. So this effort seems kind of useless, at least to me. Moving on to 1.4.x would solve the issues quite nicely. We would get updated ppp code, with full support for usage in both single and multi-threaded environments. All I say is, I'd rather invest some time moving forward than moving backward :) But I certainly see your point here, it's been a long time already ... > At this stage, I would favour an initial check-in of something close to > lwIP 1.3.2 followed by an update of the PPP code from the lwIP HEAD as > time permits. > So you would like to import my changes to ppp? As said above, I don't really want to go back to the original 1.3.2 ppp code myself. I plan to upgrade my own application to lwip 1.4.x soon and get the remaining changes of my ppp code (mostly 'record' support for debugging ppp connections using wireshark) upstream. Of course, when we have 1.3.2 in the eCos repository, I could provide patches for the upgrade to 1.4.x. Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-23 15:46 ` Simon Kallweit @ 2010-01-25 11:44 ` John Dallaway 2010-01-25 16:35 ` Simon Kallweit 0 siblings, 1 reply; 11+ messages in thread From: John Dallaway @ 2010-01-25 11:44 UTC (permalink / raw) To: Simon Kallweit; +Cc: eCos developers Hi Simon Simon Kallweit wrote: >>>> c) There are a lot of small changes under src/netif/ppp/ including >>>> function renaming. I understand that you have your own PPP requirements >>>> to consider but I think we should stick closer to the master sources >>>> for the CVS check-in. Unless your changes have already been accepted >>>> upstream? >>>> >>> Well, yesterday night I have checked the lwip HEAD, and it looks like >>> there has been lots of work done in the ppp departement. It now supports >>> polling and multi-threaded support out of the box. So it might be >>> considerable to directly use the current HEAD for inclusion into eCos >>> and keep it updated with the lwip repository until we hit the next >>> stable release. Backporting the ppp changes to the 1.3.2 codebase is a >>> bit troublesome as the internal timeout framework has changed a bit and >>> we would have to backport this too. I would pledge for the use of the >>> 1.4.0 development tree. What do you think about this? >> >> We always seem to be waiting for the next version of lwIP. :-) > > True, true. But, with the original 1.3.2 lwip code, ppp can only be used > in a multi-threaded environment. I'd have to adapt the CDL etc. for the > vanilla 1.3.2 codebase and could not use it in my own projects. So this > effort seems kind of useless, at least to me. Moving on to 1.4.x would > solve the issues quite nicely. We would get updated ppp code, with full > support for usage in both single and multi-threaded environments. All I > say is, I'd rather invest some time moving forward than moving backward > :) But I certainly see your point here, it's been a long time already ... > >> At this stage, I would favour an initial check-in of something close to >> lwIP 1.3.2 followed by an update of the PPP code from the lwIP HEAD as >> time permits. > > So you would like to import my changes to ppp? As said above, I don't > really want to go back to the original 1.3.2 ppp code myself. > I plan to upgrade my own application to lwip 1.4.x soon and get the > remaining changes of my ppp code (mostly 'record' support for debugging > ppp connections using wireshark) upstream. Of course, when we have 1.3.2 > in the eCos repository, I could provide patches for the upgrade to 1.4.x. OK. I've taken a look at src/netif/ppp/ in the upstream CVS HEAD. There are, indeed, a lot of changes. I appreciate that you do not want to put effort into unpicking your own PPP-related changes for the initial check-in. I do not want to delay the check-in further, so the remaining options are: a) Check-in src/netif/ppp/* from upstream lwIP 1.3.2 for now and warn eCos users that lwIP PPP is not yet supported. We could remove the PPP-specific CDL items for to avoid confusion. People who want to experiment with lwIP PPP immediately can still fetch your tarball to make use of your current PPP changes. b) Check-in src/netif/ppp/ from your contribution. We would have to advise eCos users via CDL display strings and comments that the PPP API and underlying functionality is non-standard and subject to significant change in the near future. May be just append " (experimental)" to the display string for CYGPKG_LWIP_PPP and mention that this feature is "subject to alignment with the lwIP 1.4.x API" in the description string. Having thought long and hard about this, I'm reasonably comfortable with option (b) so long as we're all clear that the PPP implementation is non-standard and will be replaced by something closer to the upstream sources. It does not seem right to reject a well-tested lwIP PPP implementation in favour of ... nothing usable. One other minor issue I've just noticed. Could you add CYGPKG_NET_LWIP_CFLAGS_ADD and CYGPKG_NET_LWIP_CFLAGS_REMOVE CDL options for manipulating the compiler switches in line with the majority of other eCos packages please? John Dallaway eCos maintainer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwip 1.3.2 port 2010-01-25 11:44 ` John Dallaway @ 2010-01-25 16:35 ` Simon Kallweit 2011-05-08 8:11 ` lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ] John Dallaway 0 siblings, 1 reply; 11+ messages in thread From: Simon Kallweit @ 2010-01-25 16:35 UTC (permalink / raw) To: John Dallaway; +Cc: eCos developers John Dallaway wrote: > Hi Simon > > Simon Kallweit wrote: > >>>>> c) There are a lot of small changes under src/netif/ppp/ including >>>>> function renaming. I understand that you have your own PPP requirements >>>>> to consider but I think we should stick closer to the master sources >>>>> for the CVS check-in. Unless your changes have already been accepted >>>>> upstream? >>>>> >>>> Well, yesterday night I have checked the lwip HEAD, and it looks like >>>> there has been lots of work done in the ppp departement. It now supports >>>> polling and multi-threaded support out of the box. So it might be >>>> considerable to directly use the current HEAD for inclusion into eCos >>>> and keep it updated with the lwip repository until we hit the next >>>> stable release. Backporting the ppp changes to the 1.3.2 codebase is a >>>> bit troublesome as the internal timeout framework has changed a bit and >>>> we would have to backport this too. I would pledge for the use of the >>>> 1.4.0 development tree. What do you think about this? >>> We always seem to be waiting for the next version of lwIP. :-) >> True, true. But, with the original 1.3.2 lwip code, ppp can only be used >> in a multi-threaded environment. I'd have to adapt the CDL etc. for the >> vanilla 1.3.2 codebase and could not use it in my own projects. So this >> effort seems kind of useless, at least to me. Moving on to 1.4.x would >> solve the issues quite nicely. We would get updated ppp code, with full >> support for usage in both single and multi-threaded environments. All I >> say is, I'd rather invest some time moving forward than moving backward >> :) But I certainly see your point here, it's been a long time already ... >> >>> At this stage, I would favour an initial check-in of something close to >>> lwIP 1.3.2 followed by an update of the PPP code from the lwIP HEAD as >>> time permits. >> So you would like to import my changes to ppp? As said above, I don't >> really want to go back to the original 1.3.2 ppp code myself. >> I plan to upgrade my own application to lwip 1.4.x soon and get the >> remaining changes of my ppp code (mostly 'record' support for debugging >> ppp connections using wireshark) upstream. Of course, when we have 1.3.2 >> in the eCos repository, I could provide patches for the upgrade to 1.4.x. > > OK. I've taken a look at src/netif/ppp/ in the upstream CVS HEAD. There > are, indeed, a lot of changes. I appreciate that you do not want to put > effort into unpicking your own PPP-related changes for the initial > check-in. I do not want to delay the check-in further, so the remaining > options are: > > a) Check-in src/netif/ppp/* from upstream lwIP 1.3.2 for now and warn > eCos users that lwIP PPP is not yet supported. We could remove the > PPP-specific CDL items for to avoid confusion. People who want to > experiment with lwIP PPP immediately can still fetch your tarball to > make use of your current PPP changes. > > b) Check-in src/netif/ppp/ from your contribution. We would have to > advise eCos users via CDL display strings and comments that the PPP API > and underlying functionality is non-standard and subject to significant > change in the near future. May be just append " (experimental)" to the > display string for CYGPKG_LWIP_PPP and mention that this feature is > "subject to alignment with the lwIP 1.4.x API" in the description string. > > Having thought long and hard about this, I'm reasonably comfortable with > option (b) so long as we're all clear that the PPP implementation is > non-standard and will be replaced by something closer to the upstream > sources. It does not seem right to reject a well-tested lwIP PPP > implementation in favour of ... nothing usable. Well, I'm fine with that. Over the weekend I did initial work of an lwIP 1.4.x port. I think by the time of an official 1.4.x release, I will be able to provide an updated port for eCos. In the meantime, people can use the 1.3.2 port. > One other minor issue I've just noticed. Could you add > CYGPKG_NET_LWIP_CFLAGS_ADD and CYGPKG_NET_LWIP_CFLAGS_REMOVE CDL options > for manipulating the compiler switches in line with the majority of > other eCos packages please? I added the CDL options and also marked PPP support as "experimental", as suggested. The new tarball is at: http://download.westlicht.ch/lwip-20100125.tar.gz Best regards Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
* lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ] 2010-01-25 16:35 ` Simon Kallweit @ 2011-05-08 8:11 ` John Dallaway 2011-06-07 20:28 ` Ilija Kocho 0 siblings, 1 reply; 11+ messages in thread From: John Dallaway @ 2011-05-08 8:11 UTC (permalink / raw) To: Simon Kallweit; +Cc: eCos development list Hi Simon Simon Kallweit wrote: > Over the weekend I did initial work of an lwIP > 1.4.x port. I think by the time of an official 1.4.x release, I will be > able to provide an updated port for eCos. In the meantime, people can > use the 1.3.2 port. lwIP 1.4.0 has now been released, rather later than I had anticipated. Are you still active with lwIP and interested in working on an update for the eCos repository? It would be helpful to know your current thoughts on this. There may be others in the community who could lend support to the update and/or testing. John Dallaway eCos maintainer http://www.dallaway.org.uk/john ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ] 2011-05-08 8:11 ` lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ] John Dallaway @ 2011-06-07 20:28 ` Ilija Kocho 0 siblings, 0 replies; 11+ messages in thread From: Ilija Kocho @ 2011-06-07 20:28 UTC (permalink / raw) To: eCos development list; +Cc: John Dallaway, Simon Kallweit Hi John, Simon On 08.05.2011 09:36, John Dallaway wrote: > Hi Simon > > Simon Kallweit wrote: > >> Over the weekend I did initial work of an lwIP >> 1.4.x port. I think by the time of an official 1.4.x release, I will be >> able to provide an updated port for eCos. In the meantime, people can >> use the 1.3.2 port. > lwIP 1.4.0 has now been released, rather later than I had anticipated. > Are you still active with lwIP and interested in working on an update > for the eCos repository? It would be helpful to know your current > thoughts on this. There may be others in the community who could lend > support to the update and/or testing. In SIvA we can help with testing on small systems such as LPC-1766, STM32 + ENC424. If necessary I can apply "Platform/application specific memory settings.". (CYGSEM_LWIP_MEM_SECTION) Also I have some ideas for re-organization of "Memory options" component. Ilija > John Dallaway > eCos maintainer > http://www.dallaway.org.uk/john ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-06-07 20:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <73f9997f0907192203h77494e62u58b44ccfc7a738f4@mail.gmail.com> [not found] ` <4A65B8AE.8090204@martinlaabs.de> [not found] ` <73f9997f0907212153i743cfc7as86d2a1205c5dc7ab@mail.gmail.com> [not found] ` <73f9997f0907220421y145a62c3lb2728a132474c900@mail.gmail.com> [not found] ` <4A66F7E0.4050703@intefo.ch> [not found] ` <73f9997f1001220342h7bc1c79cl7180a184bee867f3@mail.gmail.com> 2010-01-22 12:54 ` lwip 1.3.2 port Simon Kallweit 2010-01-22 13:31 ` John Dallaway 2010-01-22 14:43 ` Simon Kallweit 2010-01-22 18:51 ` John Dallaway 2010-01-23 11:57 ` Simon Kallweit 2010-01-23 14:04 ` John Dallaway 2010-01-23 15:46 ` Simon Kallweit 2010-01-25 11:44 ` John Dallaway 2010-01-25 16:35 ` Simon Kallweit 2011-05-08 8:11 ` lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ] John Dallaway 2011-06-07 20:28 ` Ilija Kocho
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).