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

[address@hidden]

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.


Simon