From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14554 invoked by alias); 26 Oct 2009 14:29:17 -0000 Received: (qmail 14531 invoked by uid 22791); 26 Oct 2009 14:29:14 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mail04.solnet.ch (HELO mail04.solnet.ch) (212.101.4.138) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Oct 2009 14:29:07 +0000 Received: from mail04.solnet.ch ([127.0.0.1]) by localhost (mail04.solnet.ch [127.0.0.1]) (SolNet-Check, port 10024) with LMTP id yxyv8Buq9FLp; Mon, 26 Oct 2009 14:29:03 +0000 (UTC) Received: from beta.intefo.ch (static-212-101-18-64.adsl.solnet.ch [212.101.18.64]) by mail04.solnet.ch (Postfix) with ESMTP id ABA05877FF; Mon, 26 Oct 2009 14:29:03 +0000 (UTC) Received: from beta.intefo.ch ([127.0.0.1]) by localhost (beta.intefo.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Yn2qzoL74jf7; Mon, 26 Oct 2009 15:29:02 +0100 (CET) Received: from [192.168.1.20] (simon.intefo.ch [192.168.1.20]) by beta.intefo.ch (Postfix) with ESMTP id 53E5A770264; Mon, 26 Oct 2009 15:29:02 +0100 (CET) Message-ID: <4AE5B235.3050905@intefo.ch> Date: Mon, 26 Oct 2009 14:29:00 -0000 From: Simon Kallweit User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: John Dallaway CC: ecos-devel@ecos.sourceware.org Subject: Re: lwip 1.3.1 testing References: <4A8E48C2.10802@intefo.ch> <20090821184336.GA24882@ubuntu.local> <20090824201853.GA10163@ubuntu.local> <4A938008.70909@intefo.ch> <4A939599.8040703@intefo.ch> <4AE480E7.2010803@dallaway.org.uk> <4AE59D93.30000@intefo.ch> <4AE5A9FB.8020801@dallaway.org.uk> In-Reply-To: <4AE5A9FB.8020801@dallaway.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-10/txt/msg00058.txt.bz2 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