In my implementations, the ethernet driver checks the ethertype, then
calls an appropriate function to handle the input. I actually do the
calls via the netif input member, which I have initialized to point to
tcpip_input in my call to netif_add. So, I'm passing the input packets
to tcpip_input which can be found in api/tcpip.c. This function sends
a message to the tcp task's mbox using sys_mbox_post.
I believe that this is reasonably safe. The PCBs are isolated within
the tcp task, and all's right with the world. (See also my note about
using the netconn or socket api, however.)
I do have some concerns about the ARP table protections. I think that
porters/users like you and I have to do some work to make defend the
integrity of the ARP tables, despite the fact that the sample ports do
not seem to implement protections.
Scott Taggart wrote:
One additional question regarding critical code sections and
LWIP. I don’t understand how LWIP is protecting
itself from incoming frames. Presumably, incoming frames (say on an EN
interface) arrive in at interrupt time/context
and end up calling ip_input and then tcp_input. tcp_input (as just one
example) manipulates the pcb lists w/o protection. Suppose a another thread
happens to also be manipulating a pcb list when an
inbound EN frame arrives? Is LWIP assuming that all inbound frames
will be processed by a polling model? Even then, the thread that polls
is not guaranteed to run to completion before another thread runs (e.g.,
the polling input thread could be interrupted by another thread for
vice-versa).
Can someone explain the inbound packet path protection
mechanism to me?
Thanks,
Scott
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
--
E-mail signature
Jim Gibbons
|
address@hidden
|
Gibbons and Associates, Inc.
|
TEL: (408) 984-1441
|
900 Lafayette, Suite 704, Santa Clara, CA
|
FAX: (408) 247-6395
|
|