Re: [lwip-devel] PPP single threaded

[Alain M.]

address@hidden escreveu:
> > 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.
> Sys_jiffies is supposed to be the number of ticks since system 
> startup, wrapping around (so effectively only useful for a delta). In 
> task #7235 (I guess it was), we had the idea to use this and a define 
> of how much tick per ms (or ms per ticks, depending on tick speed) to 
> calculate ms since system startup.
Most embedded already have a function to return elapsed ms in a long 
variable, so I believe that we can have a  single macro that returns ms. 
I am makeing one that even has a 32 bit hw counter for that (Cortex) It 
will make things most efficient. Something line these

# define ppp_milisec()  (NutMilieconds())
# define ppp_milisec()  (systick()*54L)
# define ppp_milisec() (MACRO_TO_READ_MS_FROM_HW)
> If you implement this for PPP, we could use it for standard 
> sys_timeouts with NO_SYS=1 in lwIP.
> > > 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.  
> As someone who doesn't use PPP (even running it on win32 or unix, I'm 
> lacking a counterpart), I still have one proposal: I think from the 
> lwIP architechture point of view, it would be nice if PPP would be 
> running in the main lwIP thread - like all the other protocols. This 
> would of course only work if it were implemented statemachine-like, 
> not blocking as it is now.
>
> The benefit would be that it would run with and without threading: the 
> only difference would be the application (e.g. sockets run in an own 
> thread vs. raw API running as callbacks) and the I/O, which can be 
> blocking in a seperate thread or non-blocking in the lwIP thread.
>
> Would that be the way you want to go?
NO. The reason is that in many cases (like mine) during a ppp reconnect 
I need to attend other things. So my suggestion is: put it all in a 
single threaded *function*, then I can call it in another thread or it 
can be called from main.

BUT... I believe that this will not satisfy single threaded users, in 
that case, the ideal situation would be to have a simple sequential 
state machine that can be polled.

The most important point od KIS - Keep it simple, I will never use PPP 
in single thread, I am interested in a more *understandable* version. 
Here it took 2 persons 3 days just to understand that PAP was missing, 
that is *absurd*... And that was not with a contrib example that is 
still non functional, but I used an example from the list history...
> > I haven't dug into the PPP code enough to see through. But it seems 
> > to be a bit messy in parts ... 
I agree, but U would not say messy. It looks like each part is well 
made, but there are too many parts, woven in a highly misterious maner.

Alain