Hi Simon
Simon Kallweit wrote:
> 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.
I would recommend a "radio button" approach for mutually exclusive modes
which have associated source files. Something like:
cdl_interface CYGINT_LWIP_MODES {
display "Enabled lwIP modes"
no_define
requires 1 == CYGINT_LWIP_MODES
description "This interface is used to force mutually exclusive
selection of the available lwIP modes."
}
cdl_option CYGFUN_LWIP_MODE_SIMPLE {
display "Simple mode"
implements CYGINT_LWIP_MODES
compile ecos/simple.c
}
cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL {
display "Sequential mode"
implements CYGINT_LWIP_MODES
compile ecos/sequential.c
}
> 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.
It would be best to use another CDL interface to enable compilation of
this code. Something like:
cdl_interface CYGINT_LWIP_SIO_REQUIRED {
no_define
display "Items requiring lwIP serial operations"
description "Items requiring use of the lwIP serial operations code
should implement this interface."
}
cdl_option CYGFUN_LWIP_SIO {
display "Serial operations support"
calculated { CYGINT_LWIP_SIO_REQUIRED > 0 }
compile ecos/sio.c
}
cdl_component CYGPKG_LWIP_SLIP {
implements CYGINT_LWIP_SIO_REQUIRED
compile ...
...
}
cdl_component CYGPKG_LWIP_PPP {
implements CYGINT_LWIP_SIO_REQUIRED
compile ...
...
}
This is a little more complicated than a simple "requires
CYGFUN_LWIP_SIO" but ensures that CYGFUN_LWIP_SIO becomes disabled when
the number of components requiring it falls to zero.
>>>> 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.
I thought we had concluded that we should treat lwIP PPP as a separate
project which would require liaison with the upstream lwIP
maintainer(s). Is there anyone else in the eCos community who is able
and willing to work on this?
>> 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?
Yes, although it might sometimes also be helpful to confirm a static IP
address.
John Dallaway
