On Fri, 2007-03-02 at 22:57 +0100, Goldschmidt Simon wrote: > 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.
Sounds like a reasonable suggestion to me. I'm slightly concerned by you saying that the tcpip_input() function wouldn't be needed anymore. Can you explain why? > 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()). Any raw API users/experts care to comment on this aspect? Would be nice if we could come up with a simple solution that addressed this problem for all APIs. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
