Re: lwip 1.3.1 package

[John Dallaway <john at dallaway dot org dot uk>]

Hi Simon

Simon Kallweit wrote:

> I have updated my lwIP package with the final 1.3.1 release. There are
> changes in two areas, and I wonder how to tackle them:
> 
> 1. SLIP polling support
> 
> I changed the SLIP netif to support polling, so it does not need to run
> in it's own thread when resources are low. I submitted the patch to lwip
> quite a bit of time ago, but there were no reactions:
> 
> http://savannah.nongnu.org/bugs/?26397
> 
> I could of course remove my changes, but then the eCos package will not
> support SLIP in the simple/polled mode. So I'd also have to change some
> of the glue code. I would rather like to keep SLIP polling support in.

I see that Kieran Mansley has replied to your recent follow up on bug
26397. If you can persuade him to accept the patch it would be good to
keep your SLIP polling support in the eCos package. No need to wait for
the next lwIP release.

> 2. PPP
> 
> There are quite a bit of changes I made to the PPP code:
> 
> * put code more in line with lwip coding style (mostly renaming)
> * added a simple chat component, to connect a modem to the peer
> * added support for PPP dumps (wireshark)
> * added polling support
> * added an eCos testcase (only for simple/polled mode)
> 
> If I restore the original PPP code as suggested, I will also have to
> adapt the glue code and configuration. I would remove the testcase and
> generally mark PPP as experimental. The other way would be to try and
> clean PPP more up, and get the changes commited to lwip, but then we
> would have to wait for another release.

The two scenarios are:

a) Your PPP changes are built upon over time by you and/or other people
and ultimately accepted into lwIP.

b) PPP is fixed in lwIP in a different way, rendering your patches
incompatible and obsolete.

Which do you think is the more likely scenario based on your knowledge
of the lwIP project and your own availability/inclination to work on PPP?

John Dallaway