|
From: | address@hidden |
Subject: | Re: [lwip-devel] lwIP + SLIP/PPP single threaded |
Date: | Mon, 08 Dec 2008 21:06:04 +0100 |
User-agent: | Thunderbird 2.0.0.18 (Macintosh/20081105) |
Simon Kallweit wrote:
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).Simon Kallweit wrote:SLIP needs to be changed [..]So it's fine if this is changed to non-blocking?
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
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 ;-)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.I was wondering what version of pppd was used for the current lwIP ppp implementation?
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.
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |