From: John Dallaway <john@dallaway.org.uk>
To: Simon Kallweit <simon.kallweit@intefo.ch>
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: lwip 1.3.1 testing
Date: Mon, 26 Oct 2009 17:13:00 -0000 [thread overview]
Message-ID: <4AE5D8B7.9070809@dallaway.org.uk> (raw)
In-Reply-To: <4AE5B235.3050905@intefo.ch>
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
next prev parent reply other threads:[~2009-10-26 17:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-21 7:11 Simon Kallweit
2009-08-21 7:43 ` John Dallaway
2009-08-21 9:12 ` Edgar Grimberg
2009-08-21 18:43 ` Sergei Gavrikov
2009-08-24 20:18 ` Sergei Gavrikov
2009-08-25 6:09 ` Simon Kallweit
2009-08-25 7:41 ` Simon Kallweit
2009-08-25 12:08 ` Sergei Gavrikov
2009-08-25 20:33 ` Sergei Gavrikov
2009-08-26 6:38 ` Simon Kallweit
2009-08-26 8:43 ` Sergei Gavrikov
2009-08-26 20:46 ` Sergei Gavrikov
2009-08-27 7:17 ` Simon Kallweit
2009-08-27 8:03 ` Sergei Gavrikov
2009-10-25 16:46 ` John Dallaway
2009-10-26 13:00 ` Simon Kallweit
2009-10-26 13:54 ` John Dallaway
2009-10-26 14:29 ` Simon Kallweit
2009-10-26 17:13 ` John Dallaway [this message]
2009-10-27 13:06 ` Simon Kallweit
2009-11-20 10:24 ` John Dallaway
2009-12-07 13:41 ` Simon Kallweit
2009-12-17 10:45 ` John Dallaway
2010-01-19 12:07 ` John Dallaway
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE5D8B7.9070809@dallaway.org.uk \
--to=john@dallaway.org.uk \
--cc=ecos-devel@ecos.sourceware.org \
--cc=simon.kallweit@intefo.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).