From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12855 invoked by alias); 25 Jan 2010 16:35:39 -0000 Received: (qmail 12846 invoked by uid 22791); 25 Jan 2010 16:35:38 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail01.solnet.ch (HELO mail01.solnet.ch) (212.101.4.135) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 25 Jan 2010 16:35:33 +0000 Received: from mail01.solnet.ch ([127.0.0.1]) by localhost (mail01.solnet.ch [127.0.0.1]) (SolNet-Check, port 10024) with LMTP id EIXiVyS9GXkQ; Mon, 25 Jan 2010 16:35:29 +0000 (UTC) Received: from beta.intefo.ch (static-212-101-18-64.adsl.solnet.ch [212.101.18.64]) by mail01.solnet.ch (Postfix) with ESMTP id C20204FE0A; Mon, 25 Jan 2010 16:33:29 +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 xDsxywJl7a6J; Mon, 25 Jan 2010 17:33:06 +0100 (CET) Received: from [192.168.1.20] (simon.intefo.ch [192.168.1.20]) by beta.intefo.ch (Postfix) with ESMTP id E1A5F77029C; Mon, 25 Jan 2010 17:33:06 +0100 (CET) Message-ID: <4B5DC7C4.407@intefo.ch> Date: Mon, 25 Jan 2010 16:35:00 -0000 From: Simon Kallweit User-Agent: Thunderbird 2.0.0.23 (X11/20090817) 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> <4B5B19B6.6080802@intefo.ch> <4B5D842C.5090501@dallaway.org.uk> In-Reply-To: <4B5D842C.5090501@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/msg00009.txt.bz2 John Dallaway wrote: > 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. Well, I'm fine with that. Over the weekend I did initial work of an lwIP 1.4.x port. I think by the time of an official 1.4.x release, I will be able to provide an updated port for eCos. In the meantime, people can use the 1.3.2 port. > 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? I added the CDL options and also marked PPP support as "experimental", as suggested. The new tarball is at: http://download.westlicht.ch/lwip-20100125.tar.gz Best regards Simon