[Top][All Lists]

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

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

From: Simon Kallweit
Subject: Re: [lwip-devel] lwIP + SLIP/PPP single threaded
Date: Mon, 08 Dec 2008 21:25:51 +0100
User-agent: Thunderbird (Macintosh/20081105)

address@hidden schrieb:
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).

sio_send and sio_recv are obviously blocking. Is sio_read and sio_write designed to be purly non-blocking? My idea was just to change the slipif code to use the sio_read and sio_write. The sio interface can then be implemented to either be blocking or non-blocking. Does this make sense? Then the same code could be used for blocking and non-blocking usage.

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'll have a look.

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...

This may be a good idea :)

reply via email to

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