Re: lwip 1.3.1 testing

[Simon Kallweit <simon dot kallweit at intefo dot ch>]

John Dallaway wrote:
> Hi Simon
>
> Simon Kallweit wrote:
>
> > > The lwIP CDL script currently builds ecos/sio.c unconditionally so
> > > CYGPKG_IO_SERIAL is required even when both PPP and SLIP are disabled.
> > > It would be good to compile ecos/sio.c via a CDL option which is
> > > "calculated { CYGPKG_LWIP_PPP || CYGPKG_LWIP_SLIP }" if other source
> > > code will permit this.
> > sio.c is always compiled, but there is an #ifdef which includes the code
> > only when either CYGPKG_LWIP_SLIP or CYGFUN_LWIP_PPPOS_SUPPORT is
> > active. Also, CYGPKG_IO_SERIAL_DEVICES is only enabled if either SLIP or
> > PPPoS support is enabled. Do you think solving that dependency in CDL is
> > the better approach?
>
> OK, it seems that this issue has already been resolved. I was looking at
> a slightly older revision of sio.c. As a general rule, it's preferable
> to compile only those source code files which are needed. Clearly the
> most important thing is to ensure that the resulting binaries are not
> bloated with unused code/data.

I can still change that. I just wonder what's the best approach here. 
Currently there is an option CYGIMP_LWIP_MODE which lets the user select 
"Simple" or "Sequential" mode. Should I remove this option in favor of 
two mutually exclusive components so I can only compile the simple.c or 
sequential.c? I can also create two pseudo components which are 
calculated by CYGIMP_LWIP_MODE == "Simple/Sequential" to compile the 
respective file, but this will introduce bloat in the configuration tool.

The same applies to sio. I can add a new package CYGPKG_LWIP_SIO which 
is required by both PPPoS and SLIPIF. I think the best place would be 
the "APIs" section as the SIO may be also used for other purposes than 
lwIP's internal. So a user could enable sio without using SLIPIF or PPPoS.

What do you think?

> > > How is you own testing of lwIP 1.3.1 progressing?
> > Well, I'm currently using devices with lwIP 1.3.1 in field tests. They
> > run in the 'simple' mode (single-threaded) and use PPP for GPRS
> > connections via a GSM modem. I have not seen any issues with the current
> > port. The devices run for days until they may be power-cycled for
> > updates or maintenance.
> >
> > Application development is done on the synthetic target, using a
> > simulated GSM modem, simulating GPRS connections by spawning a local PPP
> > server. No issues have occurred with this configuration either, although
> > runtimes are usually only minutes to hours.
>
> So I think we should roll this out to eCos CVS soon. This will help with
> further testing coverage.

There is still one area which needs cleanup, PPP :/ I'm still not sure 
what we're going to do with that. I need single-thread support for PPP 
in my applications, but unfortunately this breaks multi-thread support 
and adds code changes which are not currently in the lwIP tree. Best 
would be to go with the current lwIP code, but this is also broken in 
places! And I currently don't have much time to sort this out properly.

> One minor point: It would be very useful for the stack to report its own
> IP address on the diagnostic channel.

I'll try to implement this. I guess you're mainly talking about DHCP IPs 
right?

Simon