[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] lwIP + SLIP/PPP single threaded

From: address@hidden
Subject: Re: [lwip-devel] lwIP + SLIP/PPP single threaded
Date: Mon, 08 Dec 2008 21:06:04 +0100
User-agent: Thunderbird (Macintosh/20081105)

Simon Kallweit wrote:
Simon Kallweit wrote:
SLIP needs to be changed [..]
So it's fine if this is changed to non-blocking?
Not exactly changed: my guess is people still need the blocking version... But you could modify it to allow both a blocking an a nonblocking mode (e.g. selectable by a define which uses NO_SYS as default).
This would need me to move the local variables of the slipif_input() function to some private struct attached to the netif. What's the best solution for that? Is it fine to allocate some memory during slipif_init call and use netif->state as a pointer to the struct? Or is there some other preferred way?
That's the way to do it.
The timeout management of lwIP is fine, but if I'm going to use NO_SYS=1, the timeout system is just empty macros. And that's exactly what I'm aming for.
Oh, I forgot that. There has been an effort changing the timeout management some while ago but we delayed it until after the 1.3.0 release. Since that is done now, you/we could take a look at task #7235 again: http://savannah.nongnu.org/task/?7235
I was wondering what version of pppd was used for the current lwIP ppp implementation?
It was just my rough guess that the PPP netif is adapted from the Unix pppd package. A diff at least shows some similarity, so I was wondering if it would be worth updating to the current pppd implementation.
That's interesting. I didn't know the source of the PPP implementation, but developing it from scratch can't be that much fun either ;-)
Unfortunately this looks like quite a bit of work ...
I'd have thought so... I would try the current version first.

If you wanted to test lwIP PPP, I'd suggest to get it running with the current multithreading implementation first. If you get it to run with the unix or win32 port in some kind of loopback mode (to have master and slave running on one computer), I could imagine taking a look or two at it if I find the time, although that could take a while...

Converting the current implementation to a state based nonblocking mode should not be that hard after all.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]