From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10532 invoked by alias); 23 Jan 2010 14:04:48 -0000 Received: (qmail 10269 invoked by uid 22791); 23 Jan 2010 14:04:47 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout02-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 23 Jan 2010 14:04:43 +0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100123140440.RXWZ4474.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Sat, 23 Jan 2010 14:04:40 +0000 Received: from cog.dallaway.org.uk ([213.106.93.52]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100123140440.RQWF21638.aamtaout02-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Sat, 23 Jan 2010 14:04:40 +0000 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id o0NE4bUr014746; Sat, 23 Jan 2010 14:04:37 GMT Message-ID: <4B5B01F5.6060207@dallaway.org.uk> Date: Sat, 23 Jan 2010 14:04:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Simon Kallweit CC: eCos developers Subject: Re: lwip 1.3.2 port References: <73f9997f0907192203h77494e62u58b44ccfc7a738f4@mail.gmail.com> <4A65B8AE.8090204@martinlaabs.de> <73f9997f0907212153i743cfc7as86d2a1205c5dc7ab@mail.gmail.com> <73f9997f0907220421y145a62c3lb2728a132474c900@mail.gmail.com> <4A66F7E0.4050703@intefo.ch> <73f9997f1001220342h7bc1c79cl7180a184bee867f3@mail.gmail.com> <4B599FDA.7020808@intefo.ch> <4B59A8C1.5040903@dallaway.org.uk> <4B59B98F.5010106@intefo.ch> <4B59F3BB.3000800@dallaway.org.uk> <4B5AE3FF.4010708@intefo.ch> In-Reply-To: <4B5AE3FF.4010708@intefo.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2010-01/txt/msg00006.txt.bz2 Hi Simon Simon Kallweit wrote: > John Dallaway schrieb: >> Hi Simon >> >> Simon Kallweit wrote: >> >>> Ok, I merged the 1.3.2 stable code and did a few quick tests (the >>> changes are not huge). The tarball is at >>> http://download.westlicht.ch/lwip-20100122.tar.gz >>> >> >> Some initial comments based mainly on diffs against the upstream lwIP >> 1.3.2 sources and the eCos lwIP 1.1.1 port: >> >> a) On the whole, the upstream sources have very little modification. >> That's good news for future updates. Is it strictly necessary to move >> the include/ipv4/ headers into include/ as part of the eCos port? This >> seems like unnecessary effort and will also make it more difficult to >> support IPv6 in the future. > > I'll see if we can change that. Looking at this in more detail, it appears that the only way to preserve the upstream directory layout would be to add "-I$(PREFIX)/include/ipv4" to CYGBLD_GLOBAL_CFLAGS. Otherwise, other eCos packages will not find the IPv4-specific headers when #including netif.h (for example). Perhaps it is better to move the IPv4 header files as you have done already. We can think again for a future lwIP import if the IPv6 support moves beyond "experimental" status. >> c) There are a lot of small changes under src/netif/ppp/ including >> function renaming. I understand that you have your own PPP requirements >> to consider but I think we should stick closer to the master sources for >> the CVS check-in. Unless your changes have already been accepted >> upstream? > > Well, yesterday night I have checked the lwip HEAD, and it looks like > there has been lots of work done in the ppp departement. It now supports > polling and multi-threaded support out of the box. So it might be > considerable to directly use the current HEAD for inclusion into eCos > and keep it updated with the lwip repository until we hit the next > stable release. Backporting the ppp changes to the 1.3.2 codebase is a > bit troublesome as the internal timeout framework has changed a bit and > we would have to backport this too. I would pledge for the use of the > 1.4.0 development tree. What do you think about this? We always seem to be waiting for the next version of lwIP. :-) At this stage, I would favour an initial check-in of something close to lwIP 1.3.2 followed by an update of the PPP code from the lwIP HEAD as time permits. John Dallaway