From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28524 invoked by alias); 25 Jan 2010 11:44:57 -0000 Received: (qmail 28507 invoked by uid 22791); 25 Jan 2010 11:44:55 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout03-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jan 2010 11:44:50 +0000 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100125114447.JUZF10950.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Mon, 25 Jan 2010 11:44:47 +0000 Received: from cog.dallaway.org.uk ([213.106.80.48]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20100125114447.HKWB13254.aamtaout01-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Mon, 25 Jan 2010 11:44:47 +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 o0PBiiiB003813; Mon, 25 Jan 2010 11:44:45 GMT Message-ID: <4B5D842C.5090501@dallaway.org.uk> Date: Mon, 25 Jan 2010 11:44: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> <4B5B01F5.6060207@dallaway.org.uk> <4B5B19B6.6080802@intefo.ch> In-Reply-To: <4B5B19B6.6080802@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/msg00008.txt.bz2 Hi Simon Simon Kallweit wrote: >>>> 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. OK. I've taken a look at src/netif/ppp/ in the upstream CVS HEAD. There are, indeed, a lot of changes. I appreciate that you do not want to put effort into unpicking your own PPP-related changes for the initial check-in. I do not want to delay the check-in further, so the remaining options are: a) Check-in src/netif/ppp/* from upstream lwIP 1.3.2 for now and warn eCos users that lwIP PPP is not yet supported. We could remove the PPP-specific CDL items for to avoid confusion. People who want to experiment with lwIP PPP immediately can still fetch your tarball to make use of your current PPP changes. b) Check-in src/netif/ppp/ from your contribution. We would have to advise eCos users via CDL display strings and comments that the PPP API and underlying functionality is non-standard and subject to significant change in the near future. May be just append " (experimental)" to the display string for CYGPKG_LWIP_PPP and mention that this feature is "subject to alignment with the lwIP 1.4.x API" in the description string. Having thought long and hard about this, I'm reasonably comfortable with option (b) so long as we're all clear that the PPP implementation is non-standard and will be replaced by something closer to the upstream sources. It does not seem right to reject a well-tested lwIP PPP implementation in favour of ... nothing usable. One other minor issue I've just noticed. Could you add CYGPKG_NET_LWIP_CFLAGS_ADD and CYGPKG_NET_LWIP_CFLAGS_REMOVE CDL options for manipulating the compiler switches in line with the majority of other eCos packages please? John Dallaway eCos maintainer