This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: lwip 1.3.1 testing

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]