lwip 1.3.2 port

lwip 1.3.2 port

[Simon Kallweit]

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
>>

Re: lwip 1.3.2 port

[John Dallaway]

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

Re: lwip 1.3.2 port

[Simon Kallweit]

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

Re: lwip 1.3.2 port

[John Dallaway]

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

Re: lwip 1.3.2 port

[Simon Kallweit]

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

Re: lwip 1.3.2 port

[John Dallaway]

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

Re: lwip 1.3.2 port

[Simon Kallweit]

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

Re: lwip 1.3.2 port

[John Dallaway]

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

Re: lwip 1.3.2 port

[Simon Kallweit]

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

lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ]

[John Dallaway]

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

Re: lwIP 1.4.0 port planning [ was Re: lwip 1.3.2 port ]

[Ilija Kocho]

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