lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] "the ARP layer is not protected against concurrent acce


From: Kieran Mansley
Subject: Re: [lwip-users] "the ARP layer is not protected against concurrent access"
Date: Mon, 05 Mar 2007 09:09:12 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]