From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21658 invoked by alias); 23 Jan 2010 15:46:48 -0000 Received: (qmail 21648 invoked by uid 22791); 23 Jan 2010 15:46:46 -0000 X-SWARE-Spam-Status: No, hits=-2.6 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; Sat, 23 Jan 2010 15:46:41 +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 VQsLRNhVuU13; Sat, 23 Jan 2010 15:46:38 +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 E614986FCD; Sat, 23 Jan 2010 15:46:37 +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 6F+ywfVD3+V9; Sat, 23 Jan 2010 16:46:00 +0100 (CET) Received: from freakmbp-2.local (252-38-239-77-pool.cable.fcom.ch [77.239.38.252]) by beta.intefo.ch (Postfix) with ESMTPA id 1A0537702E3; Sat, 23 Jan 2010 16:46:00 +0100 (CET) Message-ID: <4B5B19B6.6080802@intefo.ch> Date: Sat, 23 Jan 2010 15:46:00 -0000 From: Simon Kallweit User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Dallaway 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> <4B5B01F5.6060207@dallaway.org.uk> In-Reply-To: <4B5B01F5.6060207@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: 2010-01/txt/msg00007.txt.bz2 John Dallaway schrieb: > 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. > Ok, now I remember why this was necessary :) > >>> 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. :-) > True, true. But, with the original 1.3.2 lwip code, ppp can only be used in a multi-threaded environment. I'd have to adapt the CDL etc. for the vanilla 1.3.2 codebase and could not use it in my own projects. So this effort seems kind of useless, at least to me. Moving on to 1.4.x would solve the issues quite nicely. We would get updated ppp code, with full support for usage in both single and multi-threaded environments. All I say is, I'd rather invest some time moving forward than moving backward :) But I certainly see your point here, it's been a long time already ... > 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. > So you would like to import my changes to ppp? As said above, I don't really want to go back to the original 1.3.2 ppp code myself. I plan to upgrade my own application to lwip 1.4.x soon and get the remaining changes of my ppp code (mostly 'record' support for debugging ppp connections using wireshark) upstream. Of course, when we have 1.3.2 in the eCos repository, I could provide patches for the upgrade to 1.4.x. Simon