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

[Simon Kallweit]

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 :)