This is the mail archive of the
mailing list for the eCos project.
Re: lwip 1.3.2 port
John Dallaway wrote:
Simon Kallweit wrote:
We always seem to be waiting for the next version of lwIP. :-)
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
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?
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
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
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: