I consider to remove the PPP_INPROC_OWNTHREAD crap in ppp-new,
as said in bugs #37278 and #37353.
1. It requires the ppp_input_thread() function to be modified to match
user system, like some did by adding the vTaskDelete(NULL); FreeRTOS
call at the end of the function, for example.
This is a tiny-tiny fonction that should be, in my opinion, on the user
port, like the Ethernet input thread we see in many Ethernet port.
2. It is actually not that thread safe.
2.1. pcb->phase IS modified by the lwIP core thread so it should at
least be set to volatile, otherwise the pcb->phase copy may live
indefinitely in CPU register. It works because of the sio_read()
function call which without doubt flush pcb->phase copy from CPU
register. I dont want to set ppp_pcb struct to volatile for obvious
performance reasons.
2.2. This function assume PCB still exists whatever is happening, which
is not the case after you called ppp_delete() function outside of this
thread. If sio_read() is blocking waiting data and pcb destroyed, it is
going to read a deallocated pcb which luckily should still have
pcb->phase set to 0 (=PHASE_DEAD) due to preallocated "control block"
structures of lwIP. Even with sio_read_abort(), there might be timings
issue due to a lack of a synchronization mechanism.
3. I dislike the sys_msleep(1), it means that systems should have at
least a 11 chr buffer at 115200/10 byte/s, and bigger with higher serial
speed, for example with 3G/HSDPA modems accessed through SPI, at 20
Mbits/s this is a ~2000 bytes buffer required to keep incoming data
during this sleep, I don't see why we require systems to do so,
sio_read() should obviously be a blocking call. I cannot easily
remove this sleep because some systems might have wrongfully used this
call as a CPU idle feature with a non blocking sio_read() call.
Free the control block, clean everything except the PPP PCB itself
and the netif, it allows you to change the underlying PPP protocol
(eg. from PPPoE to PPPoS to switch from DSL to GPRS) without losing
your PPP and netif handlers.
Created new ppp_over_X_create() functions which only prepare the PPP session without starting it
Removed ppp_reopen() and all of its sub ppp_over_X_reopen()
Removed PPPoL2TP reconnect() function, merged to connect()
Added ppp_open() able to start or restart any session
these are the compiler warnings I get with the head of ppp-new. All
of them are trivial, [...] (I'm using IAR EWARM 6.4).
ppp.c
Warning[Pe550]: variable "c" was set but never used
lwip\src\netif\ppp\ppp.c 1012
Warning[Pe111]: statement is unreachable
lwip\src\netif\ppp\ppp.c 1132
Warning[Pe111]: statement is unreachable
lwip\src\netif\ppp\ppp.c 1377
Warning[Pe111]: statement is unreachable
lwip\src\netif\ppp\ppp.c 1412
utils.c
Warning[Pe186]: pointless comparison of unsigned integer with zero
lwip\src\netif\ppp\utils.c 210
The only way PPPoE or PPPoL2TP disconnect it through ppp_link_terminated(),
therefore PPP is always already down, so we don't need to ask PPP to hup or stop.
This is now the user choice to re-establish the session in the link status callback
by either calling the ppp_reopen() to re-establish or ppp_delete() to free the PPP
control block. Without user intervention, the PPP control block now stay in the dead
phase, allowing the user to re-establish or delete the control block later.
Option PPP_FCS_TABLE is created which controls if PPPoS FCS calculation
should be done against precalculated table or by using a short algorithm.
Default value is 1, keeps old behaviour.
Setting it to 0 saves around 0.5 kB flash.
