Hi list,
CHANGELOG says:
FUTURE
...
* TODO: the ARP layer is not protected against concurrent access. If
you run from a multitasking OS, serialize access to ARP (called from
your network device driver and from a timeout thread.)
My idea was to do all ARP processing in context of the tcpip_thread (like
Frédéric suggested). In fact, I have already done so in my local sources (and
of course, it works for a while now :)
I've done this by adding 2 new functions (and some new messages) to tcpip.h/.c:
err_t tcpip_input_w_arp(struct pbuf *p, struct netif *inp);
for incoming IP packets, ETH header not removed to update ARP entry
err_t tcpip_arp_input(struct pbuf *p, struct netif *inp);
for incoming ARP packets
(tcpip_input() would not be needed any more, but you have the choice when
writing the ethernetif.c)
All access to etharp.c is thus done in the context of the tcpip_thread, which
saves us the concurrent access protection. Downside is that ARP requests take a
little longer to process (context switch) but I think that's a minor one.
AS far as I know (but I'm not using it by now), that wouldn't affect raw API
programs running without an OS, since they don't use messages, anyway. This
would simply be a matter of assigning another input function for netifs (and
maybe another input function, e.g. netif->arp_input()).
Please send your comments, or I will check in my changes and you'll have to
live with it ;-)
Simon
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
