Loading ...
Sorry, an error occurred while loading the content.

5587Re: uip_lock and d_buf usage

Expand Messages
  • spudarnia
    Mar 26, 2014
    • 0 Attachment
      Hi, Brennan,

      > I am working on a network driver and I want to make sure that I understand when I should be using uip_lock.  Is it used to protect d_buf and d_len from when they are written to when uip finishes processing them?

      Basically, whenever you executing any of the logic within net/uip, you probably should hold the lock.  The lock is what protects all of the internal data structures as well as the d_* fields in the device structure.

      That is what the lock is for.  But it might help to understand how the implementation works.  Some EMAC drivers call into the TCP/IP stack from interrupt level.  Drivers like SLIP (and PPP?), however, probably run on threads.  More courteous EMAC drivers will also perform all of the "bottom half" driver operations on the worker threads.

      For the drivers that do everything at the interrupt level, you should set CONFIG_NET_NOINTS=n and for drivers that call into the TCP/IP stack from a thread you should set CONFIG_NET_NOINTS=y.  When CONFIG_NET_NOINTS=n, uip_lock() maps to disabling interrupts.  In this case, the EMAC driver does not even need to call uip_lock() if it is doing everything from the interrupt handler ... interrupts are already disabled in this case.

      If CONFIG_NET_NOINTS=y, then uip_lock() maps to a semaphore lock.  In this case, the various threads that act on the stack get blocked by the semaphore to assure mutuallhy exlusive access to the TCP/IP stack.

      To things to note:

      1. Disabling interrupts and taking a semphore have different effects.  Not just the obvious different in the scope of the lock but in other ways as well.  For example, if the lock is a semaphore and you wait for some event, then the stack remains locked while you wait.  If the lock is through disabling interrupts, then the lock will be lost while the thread waits.

      2. If you are trying to something like I think you are doing, then you might need both:  If you have multiple network devices and one runs from the interrupt level (such as a simple Ethernet MAC driver) and the other runs from a thread (like a PPP driver), then there may be a problem.  I might work okay to run with CONFIG_NET_NOINTS=n, but just be aware of the #1 issues.

      Does that answer the question?
      Greg
    • Show all 4 messages in this topic