[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] PPP single threaded
Re: [lwip-devel] PPP single threaded
Thu, 11 Dec 2008 17:08:33 +0100
Thunderbird 184.108.40.206 (X11/20081125)
Alain M. wrote:
I am new to lwip but I hope that I can help. I have been working with
PSilva, I did most of the protocol decoding to find the problem...
I've put some work into getting PPP working in a single-threaded
(NO_SYS = 1) environment.
My first suggestion is that you make it over a Linux port, it really
helps A LOT to debug. Peter's test is running, but with threads, it
should be relatively easy to remove the threads. Al least it will make
it easyer FOR ME to help :)
Well, I'm actually working with an eCos port, and have my eCos running
as a synthetic target on a linux host. I don't need real hardware to
test, so to speak. I have a GSM modem attached on a serial port, and
this all works so far.
I've also put some time into refactoring the existing PPP code to
match more with the rest of lwIP, mostly renaming though. I've also
implemented a really simple 'chat' module, to setup a GPRS
connection. Now I wonder if the effort should be made to bring this
all back into lwIP. There is still a lot to do, but it would probably
be worth it.
Please, do ...
is jiffies used only in PPP? Usualy you will get it from the RTOS, so
I would suggest that a more generic function be used.
Let me explain what I changed in the design:
* Added a simple timesys module to PPP, this is ticked by a call to
ppp_tmr() like the rest of lwIP. This timesys implements a jiffies
counter which PPP needs in some places.
sys_jiffies() is defined in sys.h, but only used in the PPP code. It
might be a good idea to have some standard interface to retrieve the
system time, but it the current implementation lacks a lot, as there is
no definition of what a jiffy is (in PPP it's assumed to be 10ms). We
would need something like sys_get_time() which returns ms or something.
Or we can get rid of it completely and have the application call a
global timer function with delta time passed.
It also implements the timeout handlers, which are absent in lwIP for
the NO_SYS = 1 case, but still necessary in PPP. I think this puts
PPP more in line with the rest of the lwIP core.
* Added ppp_poll(pd) function, which needs to be called periodically
when in single-threaded mode.
Yes, ans yes...
This all seems to work fine so far. I wonder though, how to make this
working again in a multi-threaded environment, where we have a
separate thread to poll the serial for input.
what usualy works just fine is to put all your code into a single
thread. Simple, easy and portable. Once the connection is established,
the thread could just close.
Yes that's true, but then we would have to have the serial input and the
timeout handling to be running in the same thread, which will be
impossible if the serial input is blocking.
I guess the PPP input and output paths are not thread-safe, so they
would have to be synchronized in some way.
I am not familiar with lwip , but from my experience with other
systems, I can say this: PPP has parts:
1) making the connection, in this part noone should use the serial
port and the ppp can use sio_xxx without wory
2) once the connection is established, it is a "packet driver" just
like the ethernet one. And I believe that lwip already must have
solved that problem ;)
I haven't dug into the PPP code enough to see through. But it seems to
be a bit messy in parts ...
The current approach with calling tcpip_callback() all the time does
not look like the right way to me.
agreed, but only theoreticaly because of lack of knowledge of lwip.
I can help some... specially on a Linux port. Real hardware is with
PSilva, but I indend to get another one soon.
Is anyone interested on collaborating on this?
I have sent to the list a sio_read() that can be aborted, I can easely
conver it to a nonblocking timeouted one.
I think we should make blocking behaviour configurable in the sio
interface, so we can support both threaded and polled operation.
I've heard from quite a few guys now, who did their own hacks to get
PPP working in a single-threaded environment, and I think it's time
to get it right. Any input is welcome!
I hope that I can help, at least with chearing :)
Well it looks like quite a bit of work. One awful part of the current
PPP implementation is the mixup of PPP over Serial and PPP over
Ethernet. It's not cleanly separated, and the code is generally quite
messy. I was starting to wonder if a new port on the base of a current
pppd implementation (http://ppp.samba.org/) should be considered. But
this would lead to even more work, and I should actually start
developing the application, so my time on lwIP/PPP is a bit limited.